8000 Ensure the different generated packages are using the same transitive dependencies · Issue #2726 · wasp-lang/wasp · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Ensure the different generated packages are using the same transitive dependencies #2726

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.

Sign up for GitHub

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

Jump to bottom
Open
cprecioso opened this issue May 6, 2025 · 1 comment
Open

Ensure the different generated packages are using the same transitive dependencies #2726

cprecioso opened this issue May 6, 2025 · 1 comment

Comments

@cprecioso
Copy link
Member
cprecioso commented May 6, 2025 •
edited
Loading

Currently, we have no mechanism to ensure that transitive dependencies are the same across the different packages of a Wasp app (user code, generated sdk, server, and client).

For example, in #2672, the following version mismatch was creating a typechecking error in the todo-typescript example:

todo-typescript $ npm why engine.io
engine.io@6.5.4
node_modules/engine.io
  engine.io@"~6.5.2" from socket.io@4.7.5
  node_modules/socket.io
    socket.io@"^4.6.1" from wasp@1.0.0
    .wasp/out/sdk/wasp
      wasp@1.0.0
      node_modules/wasp
        wasp@"file:.wasp/out/sdk/wasp" from the root project

todo-typescript $ (cd .wasp/build/server && npm why engine.io)
engine.io@6.6.4
node_modules/engine.io
  engine.io@"~6.6.0" from socket.io@4.8.1
  node_modules/socket.io
    socket.io@"^4.6.1" from the root project

Important

Please note that both packages request socket.io@^4.6.1, but one is installing socket.io@4.8.1, and the other socket.io@4.7.5.

This happens because the package-lock.json from the server is being regenerated on each build, so it picks up new versions, but the one from the user code isn't, so it's stuck in the old one.

We need a mechanism to share dependencies, to ensure that such situation doesn't happen.
@cprecioso
Copy link
Member Author

A possible solution would be #1653. Another could be to add the SDK as a dependency of the server and client, to ensure that its dependencies would be taken into account when resolving the dependency tree, and thus would share them when appropriate.

@cprecioso cprecioso mentioned this issue May 6, 2025
Open
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development 2DEE

No branches or pull requests
1 participant
@cprecioso
0