Closed schmunk42 closed 6 years ago
Foxy is intended to work with Nodejs, and use all available features. The plugin does not take care to resolving dependencies in Composer, not download sources or archives, but leaves work to NPM or Yarn. So it is not possible to have a fallback solution, if Nodejs is not installed.
Why use asset-packagist.org with composer-merge-plugin ? In the first install, the composer-merge-plugin is not use by Composer to solve dependencies (because the plugin isn't installed), that is the same problem that the composer-asset-plugin.
I am not against of a fallback solution, but in this case, we lose all features of Nodejs (Npmrc, Yarnrc, Webpack, Gulp, Grunt, Babel, TypeScript, Scss/Sass, Less, etc...) to only solve the dependencies and download the sources, which is already very well done by composer-asset-plugin and asset-packagist.org. So in the end, you have to manually add the asset-packagist.org repository to your composer.json file of your project, or globally install the plugin, as for CAP.
There can be no transition between the two principles, that's why the plugin CAP has changed its name. But if you have an elegant technical solution, of course, I'm a taker.
It's not about not using foxy
- it's the opposite :)
Currently foxy
looks for packages.json
files in vendor
packages and adds their contents (via file reference) to packages.json
in your project.
Actually the only thing I am asking for is to (parse and) add or contents from a file like composer.assets.json
to packages.json
.
A composer.assets.json
could look like so:
"requirements": {
"npm-asset/jquery": "3.*"
}
The idea would be to have a quick-start for users without npm (by using AP + merge-plugin), but also a very easy and smooth transition to foxy - just by removing the merge-plugin and installing foxy in the project.
It seems to me that the composer.assets.json file uses constraints for Composer and not NPM. This will force to perform a conversion to the opposite of the CAP converter. Foxy can be extended with another Composer plugin, and in this case, it might be better to go through by this method, and not integrate the converter directly into Foxy.
I'm not opposed to adding new functionality for that this new plugin to work.
Foxy can be extended with another Composer plugin, and in this case, it might be better to go through by this method, and not integrate the converter directly into Foxy.
You mean a separate plugin which creates packages.json
-syntax from composer.asset.json
files, right.
How could I ensure that such a plugin runs before foxy?
Would it be a plugin for foxy or actually another composer plugin?
An another Composer plugin, but with Foxy in her required dependencies. To extend Foxy see the doc. If we have to add new events, we can do it.
Which events would you recommend?
And to which directories should they write packages.json
files?
The get-assets
event and probably pre-solve
event.
The directory of the installed mock package.json files is defined in the config config.foxy.composer-asset-dir
(you can see the doc).
Have you succeed to create your plugin for Foxy? And so, This issue can be closed?
Haven't found time. I am closing it.
I am working on a way to provide asset installation even without npm or yarn installed - just for quick-starting projects.
An idea woud be to use https://asset-packagist.org/ in conjunction with https://github.com/wikimedia/composer-merge-plugin - having asset definitions in separate files like
composer.asset.json
(described also in https://github.com/yiisoft/yii2/issues/14862#issuecomment-369303919) - they only definenpm-asset/xyz
...Would it be an option for foxy to use those files instead of
packages.json
as a fallback?