separate `frontend/packages/*` directory to `frontend/internal_package`

[hoshinotsuyoshi]

Task description

create new directory frontend/internal_packages

Background

          Does that mean the `frontend/packages/*` directory only contains the following four packages?

          ```
          [liam]$ git grep -l '"access": "public"'
          frontend/packages/cli/package.json
          frontend/packages/db-structure/package.json
          frontend/packages/erd-core/package.json
          frontend/packages/ui/package.json
          ```

          If so, that seems like a reasonable approach to me.

Originally posted by @hoshinotsuyoshi in https://github.com/liam-hq/liam/pull/1076#discussion_r2024252244

TODO (Optional)

• [ ]
• [ ]
• [ ]

Additional notes (Optional)

[MH4GF]

I'd like to add some additional information and proposal to this issue after investigating the current package structure.

Current Package Structure

Currently, we have the following structure:

• frontend/packages/ - Contains a mix of public-facing packages and internal packages
• frontend/internal-packages/ - Already exists with mcp-server and storybook

Packages in frontend/packages/:

__mocks__/
cli/             - Public-facing package
configs/
db/
db-structure/    - Public-facing package
e2e/
erd-core/        - Public-facing package
figma-to-css-variables/
github/
jobs/
prompt-test/
schema-parser/
script-update-fixture/
ui/              - Public-facing package

Packages in frontend/internal-packages/:

mcp-server/
storybook/

Proposal

Based on the discussion in PR #1076, I propose the following:

1. Keep only the four public-facing packages in frontend/packages/:

   • cli
   • db-structure
   • erd-core
   • ui

2. Move all other packages to frontend/internal-packages/, specifically:

   • mocks
   • configs
   • db
   • e2e
   • figma-to-css-variables
   • github
   • jobs
   • prompt-test
   • schema-parser
   • script-update-fixture

Implementation Considerations

1. Package References: We'll need to update import paths in all packages that reference the moved packages.

2. Build Configuration: Update any build, test, or other configuration that might reference these packages by path.

3. CI/CD: Ensure CI/CD pipelines are updated if they have hard-coded package paths.

4. Documentation: Update any documentation that references these package paths.

5. Phased Approach: Consider doing this migration in multiple PRs to make review easier:

   • PR 1: Move a few non-critical packages first
   • PR 2: Move the remaining packages

This reorganization will make it clearer which packages are intended for public use versus internal use, improving the project structure and maintainability.