aggregating common devDependencies?

[mindplay-dk]

The README mentions:

All features and tools are available: Npmrc, Yarnrc, Webpack, Gulp, Grunt, Babel, TypeScript, Scss/Sass, Less, etc.

These are all tools you'd use at development-time, meaning the source-code itself is going to have build-time dependencies on specific version of tools like tsc, node-sass, webpack, etc.

It's my understanding that devDependencies aren't aggregated like dependencies?

I should explain what I'm hoping to do: I'd like to use Foxy to aggregate the npm-dependencies of Composer packages - then use webpack at the project-level to build and bundle all the front-end dependencies of the Composer packages.

To run webpack, I'll need common dev-dependencies like Typescript and node-sass, etc.

In order for that to work, it's important to come up with a common set of dev-dependencies at the project-level - for example, a project that requires a Composer packages that has a devDependency on typescript^2 should conflict with another Composer package that requires typescript^3.

Same for node-sass, and for webpack itself, and so on.

Is this use-case supported? Will it support a truly modular architecture, in which Composer packages effectively contribute both server-side and front-end dependencies?

Or how do you use Foxy in practice? (I have read the documentation, but it's quite abstract and seems to mostly deal with technical details like using/configuring the tool, and only a brief overview of the practical use-cases? Please let me know if I've overlooked something!)

[schmunk42]

Will it support a truly modular architecture, in which Composer packages effectively contribute both server-side and front-end dependencies?

Actually, the goal of foxy is not that composer packages can contain asset dependencies (it turned out to be problematic in composer-asset-plugin in the long run), it rather aggregates package.json files, tries to install them and if something went wrong, it'll revert the process.

It does not make assumptions how you want to use your development tools or how you build your application.

[francoispluchino]

Foxy does not manage the asset dependency management in Composer (unlike Composer Asset Plugin), it just looking for the package.json files in PHP libraries to add the dependencies from the package.json file of the PHP library to the project's package.json file (technically, Foxy copies the package.json file to a folder and adds the path of the new package.json file in the dependencies of the project's package.json file.). Foxy does not do anything more (except a fallback in the case of an error with NPM or Yarn), everything else is delegated to NPM or Yarn, so you can use all JS tools for the front-end (which is not the case of Composer Asset Plugin).

To understand how Foxy works, I suggest you read the the FAQ and mainly:

• Why this plugin?
• What is the difference between Foxy and Fxp Composer Asset Plugin?
• How does the plugin work?
• Use Foxy

You should better understand how the plugin works and the difference with the Composer Asset Plugin (which works in the same logic as your description), and I hope I have been clearer in my explanation :-).

[mindplay-dk]

I have read the available documentation, and I understand Foxy won't run webpack for me or anything like that :-)

So I understand I'll have to do more work to make this work, but what I'm asking is, is there any reason this pattern wouldn't work? Use Foxy to aggregate front-end dependencies from Composer packages to my project, then build the collective front-end dependencies using e.g. webpack at the project-level?

Is that a bad idea?

I thought that's what this tool was for? (what else do you use it for, or how?)

[francoispluchino]

Everything will depend on your front-end project. That's why Foxy does not handle it. This is a component that you will need to create for your project (script js in webpack config, webpack plugin, etc...).

In one of my projects that still uses jQuery widgets, I added a script in the webpack config to find the files to import from the package.json files, so all the widgets are automatically added to the asset compilation.

In another project using Vuejs, in the same way, I have a script in the webpack config that adds/removes the import of the JS components into the app.js file of the project, and ditto, all the additional components of my user interface are automatically added to the compilation of the assets. Of course, the webpack script also does the specific configuration to my project (like roads by examples).

Specifically, you can do what you want in the configuration of your front-end application, Foxy only takes care the dependencies for NPM.

[francoispluchino]

NPM never installs the dependencies of the libraries. Because each library will have its own build systems. On the other hand, if several libraries have the same build system, you can create a library with all dependencies in the dependencies section, and add this library to the devDependencies section of each library. This will allow you to add this build library to the devDependencies section of the project's package.json file.

[mindplay-dk]

NPM never installs the dependencies of the libraries

You mean it never installs the dev-dependencies of libraries, right?

if several libraries have the same build system, you can create a library with all dependencies in the dependencies section, and add this library to the devDependencies section of each library. This will allow you to add this build library to the devDependencies section of the project's package.json file.

You'd still need to version that package - and if it's listed in dev-dependencies in individual packages, there's again no guarantee they're using the same versions of those build-dependencies.

So you have fewer instances of the problem, but still essentially the same problem.

I might be okay with npm-packages in Composer packages putting their dev-dependencies in dependencies though - if the idea is to ensure the Composer packages have the same build-dependencies, that's probably the only way to go about it, and kind of makes sense, since, if I'm going to build all the common dependencies at the project-level, the project is effectively going to depend on the dev-dependencies of those packages. Not sure.

Either way, you've definitely answered the question, thanks :-)

[francoispluchino]

You mean it never installs the dev-dependencies of libraries, right?

Yes.

[schmunk42]

I might be okay with npm-packages in Composer packages putting their dev-dependencies in dependencies though

Nooooo! :)

npm installs myriads of packages for development, that must not be a default.

if the idea is to ensure the Composer packages have the same build-dependencies, that's probably the only way to go about it, and kind of makes sense, since, if I'm going to build all the common dependencies at the project-level, the project is effectively going to depend on the dev-dependencies of those packages. Not sure.

If you build with webpack or any other js-tool, you need to set up your build process, which should also include the installation of devDependencies deliberately - and you should not include them in your final product.

As an additional example, with HTTP/2 minification and concatenation becomes less important and for smaller projects you might be OK without any devDependencies at all - like good old bower style.