[META] node_modules and config strategy?

[mrjmd]

When a component has system.config and/or npm dependencies, how do we maintain our per-component encapsulation while sharing dependencies?

If different components each have their own node_modules folders, which may have different version dependencies as well, how do we make everything play nicely together?

We've done some work on making system.config settings cascade up from each component's info.yml file, but we need to ensure that it's working properly and figure out what to do when different components override the same system.config variable to different values.

[ghost]

One possible solution is to go with the highest version number, disable any components using a lesser version, and display a Drupal Messages error message on view/adding that block. That would require the developer to review the component and resolve the version discrepancy, which I'm assuming is the intended outcome anyways.

I don't think we want to get into the realm of testing components for compatibility or anything.

[mrjmd]

That is a solution, but it only really addresses part of the problem (it answers different version dependencies, but not where all these node_modules live, and how to avoid npm install in component directories adding numerous instances of the same exact dependency).

I spoke some with @zhawkins about this, and he pointed me at this: https://www.npmjs.com/package/npm-deps

Needs to be tested, but I think the potential is there for this to solve a couple of different problems at once. The basic idea would be that we include a package.json file in our framework definition module (pdb_ng2), but that we use npm-deps to scan all component subdirectories for their package.json files as well and merge them together.

That way, we would run npm install from the submodule root which would deal with all the dependency management for us and create a single node_modules folder. If components had different version requirements, npm will handle that the usual way by nesting directories in node_modules for off-versioned dependencies.

There are a couple of caveats I can think of immediately... the biggest one is that we're now breaking our goal of "turn on the module and start placing components on pages, it will just work", by adding the npm-deps && npm install steps. This does come with the advantage of allowing us to get past using external files for ng2 though, our library can simply reference the files from where they'll be in node_modules after npm install is run.

The other big issue I could see arising from this is dependency pathing, but I think we should just test it out and see where we get.

[zhawkins]

RE dependency pathing: Thinking this might work given how node loads modules from the node_modules folder. Looks like it'll move to the parent directory until it finds the right module. https://nodejs.org/api/modules.html#modules_loading_from_node_modules_folders

[mrjmd]

So, that npm-deps() package seems pretty broken. I tested it out and ran into a bunch of errors, and upon taking a closer look, the repo (https://github.com/Automattic/npm-deps) hasn't been updated since 2014.

Interestingly, it was written by Automattic, the WordPress company.

It may be worth trying to fix since this does seem like exactly what we need, but the LOE just went up at least a bit.