Closed schmunk42 closed 6 years ago
Extracting the asset dependencies in a package.json
file is not complicated in itself. However there are 2 important points that pose a problem:
For the first problem, we can make a converter, however I do not want to pollute Foxy with this code, so we could have an additional Composer plugin foxy/legacy
or foxy/foxy-legacy
. This plugin will require Foxy, and will perform the conversion via an event triggered by Foxy.
So to summarize:
foxy-legacy
plugin to create a package.json
file for the NPM dependencies ; throw an exception if Bower packages are found ; and create a converter of range versions in opposition of CAP (Composer to NPM and not NPM to Composer)PS. This is still not packages.json
, but package.json
;-)
I also forgot, that the VCS repositories must be converted in the dependency versions in the package.json
file. It's a lot of work for a halftone result (potential bugs and Bower isn't unsupported).
I can already add the triggers in Foxy, which will allow any other plugin to be created, if Foxy does not officially support it.
Foxy events are added by 3f16cd09192a9c455415a6e6b2b2b6e93ea1a27b.
Wow, nice!
This issue can be closed then, please reopen if needed.
Removing NPM dependencies in Composer before the resolution by the Solver SAT may cause problems. I'll look if it's achievable.
It's not possible without a plugin installed in global mode, because the pre-dependencies-solving
event is triggered only with the already installed plugins. And even with that, it will be difficult to remove the asset packages. A package mock must be created for each version required during the resolution, and installation operations must be removed after the resolution.
Could there be a functionality to support cap syntax? Like so...
npm-
into entries inpackages.json
.Maybe even with a mapping for
bower-Xyz.js
tonpm-xyz
if needed. (optional)