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

[META] node_modules and config strategy? #52

Open
mrjmd opened this Issue May 11, 2016 · 4 comments

Comments

Projects
None yet
2 participants
@mrjmd
Owner

mrjmd commented May 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 18, 2016

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.

ghost commented May 18, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mrjmd

mrjmd May 19, 2016

Owner

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.

Owner

mrjmd commented May 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zhawkins

zhawkins May 19, 2016

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

zhawkins commented May 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mrjmd

mrjmd May 31, 2016

Owner

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.

Owner

mrjmd commented May 31, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment