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.
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.
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.