-
-
Notifications
You must be signed in to change notification settings - Fork 181
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
Refactor PackageJsonSynchronizer to prevent unintentional duplicate dependencies #841
Conversation
src/PackageJsonSynchronizer.php
Outdated
$manipulator->addSubNode('devDependencies', '@'.$phpPackage['name'], 'file:'.substr($packageJson->getPath(), 1 + \strlen($this->rootDir), -13)); | ||
$dependencies['@'.$phpPackage['name']] = 'file:'.substr($packageJson->getPath(), 1 + \strlen($this->rootDir), -13); | ||
|
||
$versionParser = new VersionParser(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Relying on the Composer version parser to parse npm constraints looks wrong to me. The syntax is not the same between both ecosystems (some parts of the syntax are common, but not everything)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and worse than that. Some syntax is the same with different meaning (so the parser would accept it but produce a different result)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it's a problem. In the current version it simply generates an invalid package.json the developer has to fix themselves. This hasn't been a common use case for Flex yet so it rarely occurs. What is the intended behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain the problem a bit more that this is solving? Is this if you install 2 packages that both have chart.js
has a peer dependency... but they one requires v2 and another requires v3?
If so, yea... it's super rare. Well, probably not a reality at all right now. I would vote to simply "do nothing". What I mean is, if you already had chart.js
in your package.json, leave it with whatever version was there. This is a problem the user will need to resolve and they will see peer dependency warnings from yarn/npm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't trying to solve it but while writing the PR I noticed it simply generated invalid JSON with 2 conflicting peer dependencies.
Apperantly I forgot the use case for peer dependencies in NPM so awesome suggestion. Thanks :)
Apologies for the delay, I had a very persistent cold the last few weeks. |
Can you please rebase? |
/cc @tgalopin could you please have a look? |
023a72e
to
db23b8d
Compare
db23b8d
to
815c96f
Compare
Thank you @codedmonkey. |
Fixes #840
Changes how
PackageJsonSynchronizer
handles dependency resolving. If a dependency is already defined under thedependencies
section of package.json, Flex won't add it again underdevDependencies
. If multiple UX bundles require the same dependency, no action is performed.Because the way
PackageJsonSynchronizer
was written, I had to change the order of the steps in the synchronization process. While it used to update the package.json for each UX dependency individually, it now resolves a list of dependencies and updates package.json at the end.I also changed how it handles incompatible peer dependencies, no action is performed by the synchronizer if multiple ux package require incompatible peer dependencies.