Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split dependencies in the new structure #1595

Open
sodic opened this issue Dec 7, 2023 · 1 comment
Open

Split dependencies in the new structure #1595

sodic opened this issue Dec 7, 2023 · 1 comment
Assignees
Labels
compiler enhancement New feature or request post-0.12.0 refactoring Keeping that code clean! restructuring

Comments

@sodic
Copy link
Contributor

sodic commented Dec 7, 2023

Note

We should do this together with #1841

In the new structure of a Wasp project (see prototype in #1584), Wasp dependencies are split into 4 groups:

  1. Project and user dependencies - listed in /package.json.
  2. SDK dependencies - listed in /node_modules/wasp/package.json.
  3. Server dependencies - listed in .wasp/out/server/package.json.
  4. Client dependencies - listed in .wasp/out/web-app/package.json.

Identify which dependencies belong to which "project" (some dependencies might be required in multiple projects) and modify the generator to output appropriate package.json files.

Also, find a way to let the users know which dependencies in the root package.json they aren't allowed to touch.

@sodic
Copy link
Contributor Author

sodic commented Feb 29, 2024

We've released Wasp 0.12.0 with some separation of dependencies, but we weren't thorough enough.

The issue still stands: figure out what belongs where and remove duplicates and redundancies.

Idea: Why not move all Wasp's dependencies from the user's package.json to the SDK's package.json. The main reasons against doing this were:

  • This packages (e.g., typescript, react) are so crucial to Wasp that they should be listed in the package.json explicitly.
  • What happens if the user (by accident) specifies one of these dependencies themselves? Does it break the app?

Finally, decide which packages can and should be peer dependencies (or dev dependencies).

Especially pay attention to:

  • Types (e.g., @types/react, @types/react-router-dom) - Where should these go? Investigate the implications of putting them into each possible location:
    • user:dependencies vs user:devDependencies vs sdk:dependencies vs sdk:devDependencies.
  • Packages Wasp implicitly needs - Packages that Wasp doesn't list as dependencies, but its code can't work without them (e.g., cors package for configuring middleware, possibley screen package for testing). This is bad API design on our part, and we should figure out what to do with those packages.
  • Core packages - Wasp's core dependencies: React, Typescript, Vite, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler enhancement New feature or request post-0.12.0 refactoring Keeping that code clean! restructuring
Projects
None yet
Development

No branches or pull requests

2 participants