Yarn: nested node_modules instead of flat when using npm2.x

[calidion]

yarn uses flat way to install packages.
it is messy and dirty.
i use npm2.x and it is clean and beautiful in its structure.
yarn should not break this when i am using npm2.x

[ljharb]

This mirrors how npm 3 and 4 install packages.

The contents of node_modules aren't supposed to be your business - npm (or yarn) manages them.

[calidion]

@ljharb
it is when you need to debug and investigate problems with installed packages.
it is easier to find files you need with tree style folders than a big list of dirs when in an ide.
listing all packages is a wasting of developers' time in searching packages and being an distraction for debugging and coding.

hope yarn will make it right again.
thanks.

[ljharb]

As soon as you upgrade to node 6 or later you'll have npm 3, and the same flat folder structure - the time to change that is years passed ¯_(ツ)_/¯

[calidion]

I won't use npm3 + until it supports nested way to install packages in my development env.
the same to yarn.

[ljharb]

@calidion i'm afraid it never will again, nor will yarn. a maximally flat structure is how every tool in the ecosystem now operates, and you can't stay on npm 2 forever.

[calidion]

no programming languages can be forever popular:)
Web assembly may give me a new opportunity someday.

[calidion]

npm3's flat structure is a very bad solution.
the flatten folders should be hidden somewhere which only keep one copy for each modules. while the visible folders should show the real structure of dependencies.
It is very easy to accomplish and natural to developers and package maintainers.

if i am the module designer, i would create two folders.
one is .packages which is flat.
the other is .structure which nested.

.packages
.structures

the .packages folder stores all packages needed.
the .structures folder stores current structure of the package or project, which is in accordance with the package.json. these folders can be soft links or shortcuts.

[ljharb]

In npm 3+, and presumably there's a similar option in yarn,npm ls prints out the nested directory structure, not the structure within node_modules - so it already does what you want without needing multiple copies of the files, or symlinks, on disk.

[calidion]

but how can i debug with the nested structure instead of using npm ls? in fact the nested folders are what i care about not the flat ones.

[ljharb]

I'm not sure why it makes debugging any harder - if you want to edit module X, you open up node, type require.resolve('x'), and then that's the path you cd into and edit. If you have a stack trace, it already tells you the path, so you don't have to look for anything.

[calidion]

how can i select these modules from ide by clicking node_modules?

[ljharb]

I'm talking about on the command line - if your IDE lacks the facility to click on a require statement and jump to the relevant code, I'd file a bug with the IDE.

[palmerj3]

npm 3 flattened the folder structure because windows cannot support very long paths. And yarn should not respect anything about your version of NPM. It doesn't use NPM to install packages (only the repository).

[sebmck]

We have no intention of reverting the way Yarn installs packages to the bloated way of npm <=2.

[Vanuan]

But how can we ensure that we don't accidentally use a package which is not in package.json?
I thought that all direct dependencies should be written in package.json explicitly. How can we know that some package we use in such an implicit way doesn't break things at some point?

[ljharb]

@Vanuan use eslint-plugin-import which has a rule to ensure that. The Airbnb eslint config also enables this rule.