Closed
Description
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
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
wdhorton commentedon Oct 11, 2016
Are you thinking this be implemented with an ESLint rule?
jasonszhao commentedon May 3, 2017
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
, andshared
. My current workaround is making a tiny change in CRA's webpack config to process the code inshared
.gaearon commentedon May 8, 2017
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.
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 commentedon May 17, 2017
done in #2189; a61be9c
dnsorlov commentedon May 20, 2017
@gaearon, if I want to import version from package.json, what should I do?
gaearon commentedon May 20, 2017
Maybe we could add an exception for this use case. @Timer thoughts?
Timer commentedon May 20, 2017
I believe supporting package.json is reasonable.
a-tokyo commentedon Jun 13, 2017
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
.20 remaining items