Use TypeScript Compiler API for Creating Interfaces, Types, and Functions

Is your feature request related to a problem? Please describe.
Yes, currently we are dealing with strings to create interfaces, types, and functions, which is non-ideal and error-prone. It also makes it harder to use TypeScript's type-checking capabilities.

Describe the solution you'd like
We should use the TypeScript Compiler API to create interfaces, types, and functions. Specifically, we should utilize createFunctionDeclaration, createTypeAliasDeclaration, and other relevant factory functions.

Describe alternatives you've considered
There shouldn't be any alternative to this.

Additional context
The following file needs to be updated:

• packages/code-generator/functions.ts

Checklist

• Add unit tests for the new implementation.
• Migrate existing string-based code generation to use TypeScript Compiler API.

We need to develop a React Single Page Application (SPA) using Vite for our ts-codegenerator. This will allow us to offer our visual TypeScript tools to users who prefer or require a standalone web application.

The SPA will use the shared component package we're creating and implement the CodeGenerator feature. We'll also integrate the codebase search feature using the JSON generation solution we're developing in a separate issue.

Checklist:

• Wait for the shared component subpackage issue to be merged #19
• Create a new Vite app in the monorepo /apps/react-spa
• Set up TypeScript config for the Vite app
• Configure ESLint for the Vite app
• Configure Tailwind for the Vite app
• Add the @visual-ts/react-components package as a dependency
• Implement the CodeGenerator feature without search feature, only manual stuff

We need to create a feature that generates a JSON file containing all scanned and parsed functions in the codebase as FunctionInfo. This will allow our SPA to have access to the codebase information without needing direct file system access.

This feature will be crucial for the upcoming React SPA project and will solve the challenge of codebase scanning in a client-side environment.

Checklist:

• Modify the existing codebase scanning function to output a JSON file
• Ensure the JSON structure matches the FunctionInfo interface
• Create a script to generate this JSON file on-demand
• Add documentation on how to use this feature
• Update the ts-codegenerator package to include this new functionality
• Test the JSON output with a variety of codebases to ensure accuracy and completeness

We need to migrate to a shared component package instead of developing components/hooks in the Next.js app. This way, we can use these pieces across any React environment, SPA, Remix or {insert technology}

The new package, @visual-ts/react-components, will contain the reusable components and hooks currently used in our Next.js app (and the ones we will create in the future 😄 )
Checklist:

• Create a new subpackage in /packages (let's call it @visual-ts/react-components)
• Set up TypeScript config for the new subpackage
• Configure ESLint for the new subpackage
• Set up Tailwind for the new subpackage
• Move relevant components and hooks from the Next.js app to the new subpackage
• Update package.json to include the new subpackage as a dependency
• Update imports in the Next.js app to use the new subpackage
• Test to ensure everything still works in the Next.js app

Code Generator can declare a variable using a function call and that function may need parameters.

Code Generator should be smart enough to grab already declared variables; and use them as params when needed.

let data = await fetchData()
let parsedData = await parseData(data);

Right now we don't support this feature. That would be a great feature if we introduce it.

Is your feature request related to a problem? Please describe.
The popover component that lets you view the function's code is not working. It worked before we implemented drag-and-drop functionality, but now it is broken.

Describe the solution you'd like
Make the FunctionInfoPopover function well again! and keep the drag-and-drop of course.

Additional context
You can find the FunctionList component in
packages/parser/src/components/project-functions/FunctionList.tsx

and the FunctionInfoPopover in
packages/parser/src/components/shared/FunctionInfoPopover.tsx

This is a good first issue! Feel free to contribute.

Is your feature request related to a problem? Please describe.
Yes, the current project structure makes it difficult to manage imports within packages. When importing modules or components from different directories within the same package, we have to use relative paths, which can become hard to maintain as the project grows. While we have successfully configured path aliases for imports across packages, we are facing challenges when it comes to local imports within the same package.

Describe the solution you'd like
The desired solution is to implement path aliases that allow us to import modules or components within the same package using a consistent and concise syntax. Instead of using relative paths like ../../../someModule, we could use an alias like @myPackage/someModule. This would improve code readability, maintainability, and make it easier to refactor code without breaking imports.

Describe alternatives you've considered
This PR (however this solution doesn't have autocomplete, and needs some investigation).

Another alternative is to use project-wide path aliases, but this approach may not be optimal for local imports within packages, as it could lead to naming conflicts or make it harder to reason about the import paths.

Additional context

Right now, our alias imports are autocompleted, but they fail when building:

Standardize ESLint Configuration Across the Project

Background

Currently, the ESLint configurations are inconsistent across the entire project. The following directories and packages are using different ESLint configurations:

• apps/next
• apps/docs
• packages/ui
• packages/code-generator
• packages/parser

This inconsistency can lead to code style discrepancies and make it harder to maintain a consistent codebase across the project.

Additionally, there is an existing /eslint-config package in the packages directory, which can potentially be used as the main source for ESLint configuration across the project.

• Find a eslint config that can be used in both apps and the packages
• Update eslint-config package
• Use it across the project
• Add changes and rules to the documentation