Create-react-app: Document reserved words for folder names (importing)

Created on 23 May 2017  路  17Comments  路  Source: facebook/create-react-app

macOS Sierra, React-Scripts 1.0.5, NODE_PATH=src in .env file

I've been keeping my String constants in src/constants and exporting them all using an index (mainly Redux actions). I just tried:

import {DATA_SUCCESS, DATA_REQUEST, DATA_FAILURE } from 'constants'

but they came through as undefined. Realising the index wasn't being imported correctly, I then changed the name of the folder and it worked like the 0.9.x days. Could we please have a list of all the reserved words?

Repo to demonstrate issue is here: https://github.com/will-stone/cra-reserved-folder-names
Check console for both positive and negative tests, called from app.js

Changing the folder name to all caps allows this to work too. I think I'll stick with this as a solution.

claimed starter question stale documentation

Most helpful comment

@will-stone They are supported and this issue is still open. Just saying this is a good example of why relying on them is fragile.

@YoginAlex Please provide a project reproducing the issue. There is too little information to help you. The fact that it worked in 0.9.x does not mean anything: it used Babel ES6 modules CommonJS interop which does not conform to the spec and has many edge cases.

All 17 comments

This sounds like a bug to me, going to tag this for later review.

Can you explain the problem in more detail? Was there a specific regression that caused this?

I only just noticed it; upgraded an established project from 0.9.x to 1.0.5. Not sure what more information I can provide, but let me know if you need anything specific.

This is a known webpack bug(?), see https://github.com/webpack/webpack/issues/4159
constants being a builtin module for node, thus having higher priority.

I have a something like this, I think...

After upgrade from 0.9.5 to 1.0.5:

./src/components/Masters/Masters.js
72:24-30 'front-components' does not contain an export named 'Button'.

_front-components_ - private component library, installed from git+ssh
In exports:

import { Table, SmartTable, Button } from './components';

export default {
  Table: Table,
  SmartTable: SmartTable,
  Button: Button
};

For _SmartTable_ - no problem, but _Button_... confuse...

On 0.9.5 - problem not repeated.

npm -v 4.6.1
node -v v6.10.1
"react-scripts": "^1.0.5"
macOS 10.12.5 (16F73)

@will-stone

This is a good example of why NODE_PATH=src is dangerous and we don鈥檛 officially recommend it 馃槈
I guess it would be reasonable for Webpack to completely blacklist this internal Node module, but it鈥檚 something we鈥檒l need to discuss with Webpack.

@YoginAlex

Your problem is unrelated, and appears to be a genuine mistake. You can鈥檛 import { Button } if you used export default { Button }. That鈥檚 just not how imports work: you import a named export called Button but your module provides only default export. Please read about the difference between named and default exports.

For import { Button } to work, you would need to export { Button }, not export default { Button }.

@gaearon but.. but... relative paths are soooo tedious 馃檮 Absolutes may not be officially _recommended_ but presumably they are officially _supported_ (hence your patches to 1.0.0), if not, is this stated somewhere? Should we all be converting back to relative paths?

@gaearon thx!
But it not work :)

_Table_ and _SmartTable_ import normal - on 1.0.5.
And, I repeat, on 0.9.5 - all import work great.

@will-stone They are supported and this issue is still open. Just saying this is a good example of why relying on them is fragile.

@YoginAlex Please provide a project reproducing the issue. There is too little information to help you. The fact that it worked in 0.9.x does not mean anything: it used Babel ES6 modules CommonJS interop which does not conform to the spec and has many edge cases.

It looks like adding node.constants: false to the webpack config will fix this. Is this a possibility or would that break other stuff?

@will-stone that might break any one of your packages that relies on it; however, this is the expected behavior because node_modules/ or node internals always take precedence.

I'd be open to a PR which discloses less-obvious node internals to lookout for (basically this list).
This section would probably be best under absolute imports (the NODE_PATH=src hack) as one of the caveats.

Is this issue still relevant? I would like to contribute

I believe so, so you can go ahead and give it a whirl!

sure, if anyone wants to join let me know. Thank you @Timer

@Timer Status update: working on the issue, I got stuck migrating an app at work so that took a while.

No problem! 馃槃

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

oltsa picture oltsa  路  3Comments

barcher picture barcher  路  3Comments

Aranir picture Aranir  路  3Comments

jnachtigall picture jnachtigall  路  3Comments

fson picture fson  路  3Comments