Open sodic opened 7 months ago
This might be become redundant if we go with aliasing wasp deps, since then there is no conflict anymore and we don't need the check anymore.
Edit by @sodic: this one: https://github.com/wasp-lang/wasp/issues/1644
In order to make this happen, we would need to write a parser for semver so we can semantically compare Wasp dep version with user's dep version.
We decided to shelf this task because we feel it's a part of a bigger picture (npm workspaces, aliasing npm deps etc.) and this issue might disappear all together in a different future setup.
This is how how Wasp consolidates user dependencies with framework dependencies as of Wasp 0.12.0 (taken from original discussion in https://github.com/wasp-lang/wasp/pull/1602#discussion_r1431438802):
For each dependency, decide which version we allow.
package.json
, Wasp lists it in{sever,web-app}/package.json
.package.json
, Wasp installs it in the top-levelnode_modules
and doesn't list it in{sever,web-app}/package.json
(this is what this PR implements).package.json
, Wasp reports a conflict and refuses to build (this is what we already do in the old structure, this PR just keeps the behavior).Since our version conflict check uses single string comparisons (instead of semantically comparing version ranges), it sometimes reports false positives.
For example:
^1.4.1
^1.4.0
^1.4.1
, but Wasp reports a conflict.