Completely disallow importing from outside of src/, packages/ or node_modules/

[gaearon]

There shouldn’t be multiple conflicting ways to do the same thing. Currently we allow importing JS from anywhere but we don’t process it with Babel if it is outside src. This is slightly confusing and inconsistent. It also allows invalid/unsupported patterns like importing from public folder (which exists for a completely different purpose), or from build.

After #741 is implemented and we have a first-class support for multiple top-level modules in a single repo, I think we should completely disallow importing JS or assets from anywhere else. Then we would have a clear picture of what each directory is for:

node_modules # JS unprocessed by Babel, third party modules
src # JS processed by Babel, entry point
packages # JS processed by Babel, additional self-contained "packages"
public # escape hatch for non-module assets, never processed
build # build output, never processed
<other folders> # docs and other resources, never part of build output

[wdhorton]

Are you thinking this be implemented with an ESLint rule?

[jasonszhao]

The lack of Babel processing for importing outside of the src folder makes it harder for me to use code shared between the server and browser. I have three sibling folders: server, client, and shared. My current workaround is making a tiny change in CRA's webpack config to process the code in shared.

[gaearon]

Importing outside of src is not and has never been supported at all.
This is mentioned in the documentation.

I understand the difference is annoying, but you are just relying on unintentional behavior.

I have three sibling folders: server, client, and shared.

This is not really a supported way of using CRA. The supported way is to keep the project generated by CRA in the client folder.

[Timer]

done in #2189; a61be9c

[dnsorlov]

@gaearon, if I want to import version from package.json, what should I do?

[gaearon]

Maybe we could add an exception for this use case. @Timer thoughts?

[Timer]

I believe supporting package.json is reasonable.

[a-tokyo]

I think some web apps would like to import the version number, or the dependencies used by the project to list somewhere. That's why I believe supporting package.json is reasonable.