Document src/node_modules as official solution for absolute imports

[gaearon]

After a long discussion in #741 it seems to me that src/node_modules seems like the best solution for absolute imports.

It has the following benefits:

• Doesn't rely on symlinks (they don't work well on Windows).
• Works with IDEs and any existing tooling because it relies on Node resolution mechanism.
• If you really want to, you can run ln -s src/node_modules src/packages and use the "nicer" packages (or any other) folder.

This issue is a call to help to make this approach the official one. We need to:

• Document it
• Make Jest preprocess this subfolder Allow Jest to preprocess non-root node_modules #607
• Make Jest run tests in it Jest ignoring tests inside src/node_modules #1042
• Fix any other integration issues we find

If you want to work on either please leave a comment and then submit a PR!
Cheers.

[fadeojo]

I want to help but I will need someone to shadow.

[gaearon]

Feel free to jump on either of those issues and let me know if you need any help!

[tbranyen]

This is a very interesting idea! I'm wondering though if it'd make more sense to support a top-level packages directory (exactly like lerna) and symlink that to src/node_modules. This binding could exist for all create-react-apps.

src/
src/node_modules -> ../packages
packages/
public/

The reasoning for this is that typically your external modules are general purpose and not application-specific (therefore not desirable in the application source directory), and to support something like lerna. Maybe you want to do code splitting via npm packages? This would allow you to support lerna and create-react-app in the same project.

For selfish reasons, this would allow me to use create-react-app to kitchen sink/playground a bunch of lerna components.

[viankakrisna]

what's the issue with cross-env NODE_PATH=./src react-scripts start ? I think it's cleaner and more clear rather than having a node_modules inside src folder.

[gaearon]

Most people don't know about cross-env so they just write commands that don't work on Windows. This hurts open-source examples (e.g. people can't run a React example because of its reliance on Bash environment variable syntax). NODE_PATH is also considered legacy and slightly discouraged so it doesn’t feel right to promote this as a solution. Just using src as the root can also be a bit surprising, and the explicitness of node_modules has some benefits (e.g. you know for sure they’ll have priority over regular node_modules).

Ultimately I just want both ways to work, and we can document them. People can then choose whichever way they prefer.

[gaearon]

support a top-level packages directory (exactly like lerna) and symlink that to src/node_modules

I believe this is what I suggested in the opening comment (but only as opt-in):

If you really want to, you can run ln -s src/node_modules src/packages and use the "nicer" packages (or any other) folder.

It has to be opt-in though, please read the discussion about Windows issues in #741.

[daltones]

I personally like the idea of a src/node_modules, just because it's absolutely free of hacks.

But right now there's some problems with linters:

• eslint by default ignores /node_modules (that is not so bad running the command in the project directory and ignoring vendor's node_modules, but would ignore all code if running in src/).
• eslint-plugin-import has some problems with another node_modules folder (see Consider that some node_modules folders aren't vendor import-js/eslint-plugin-import#677)
• If we place .css files or similar along with components inside src/node_modules, stylelint ignores with hardcode **/node_modules/** (that would ignore every file always).

[kompot]

Another way of managing absolute paths that might have come up but could not find it in
#741

We've been using wix's wml
https://github.com/wix/wml
to get any required project structure with:

• absolute paths
• no symlinks

As project's readme states — they just use watchman to watch for certain dirs and copy files to node_modules subfolders. We've added some additional scripts to automate bootstrapping but it turned out to work really smooth.

Sure it's not an ideal solution but it seems to work really nice and does not force you to follow any conventions so it's easily can be applied to any project.

What do you think?