loader: transitive dependency loading

[IgorMinar]

what happens when we have a transitive dependency (M2) that is not in the main package.json.

That package will end up in node_modules folder of the component that depends on it (M1) and not in the main node_modules folder. That's ok for now.

But the question is will importing M2 module from module M1 still work? or will we need to adjust paths somewhere because now the modules come from different folders on the file system?

[pkozlowski-opensource]

@IgorMinar ok, so I was (naively) hoping that https://www.npmjs.org/doc/cli/npm-dedupe.html will eagerly move transitive dependencies to the main's package node_modules folder. But this is obviously not happening so M2 is going to stay inside M1's node_modules folder.

This is somehow bad as the transitive deps tree can be deep and we need to "flatten" it somehow, either during the transpilation phase or using another task. At the end of the day we need to finish with a flatten structure so require.js can load from it... or have a dedicated require config that will be able to "understand" deeper structure.

Going to play with different setups, but yeh, this might be one of the missing things / tasks to write.

[pkozlowski-opensource]

Other thought - in a typical project we are going to have 2 types of modules inside the node_modules folder:

• "real" dependencies with the code to be loaded in a browser
• dev dependencies with build tasks etc.

In this sense Bower makes it all a bit easier in the sense that one folder hosts only things to be loaded in a browser.

In any case we need to be careful not to touch dev dependencies when flattening deps tree, so all the operations should be done only on the real dependencies and not on the dev dependencies. BTW, dedupe already allows us to pass a set of modules to be taken into account during the flattening process.

[pkozlowski-opensource]

Hmm, just tested one more setup and effectivelly, https://www.npmjs.org/doc/cli/npm-dedupe.html does what it says:

Searches the local package tree and attempts to simplify the overall structure by moving dependencies further up the tree, where they can be more effectively shared by multiple dependent packages.

And further up the tree means the lowest parent of modules with overlapping dependencies and by no means the top (app) node_modules folder. Which means that the folders structure produced by npm_dedupe will be changing depending on the overall dependencies structure in the project. Which in turn means that paths will be changing as we add / remove / change dependencies and their versions.

This is pretty bad for build config as changing paths will mean tweaking of glob patterns in an app all the time :-/

So, we can't count on https://www.npmjs.org/doc/cli/npm-dedupe.html to do proper "flattening" of the overall dependency tree. I need to check what browserify is doing in this case as it should (?) be dealing with the exact same problematic.