Closed despairblue closed 8 years ago
My guess is that you have some conflicting package. I can't repro this on my machine and I only have Nuclide and vim-mode installed. When you open atom you get a lot of redboxes that seem to be about the linter, so maybe the issue is that the linter conflicts. I would try disabling the linter packages and other suspicious packages until the issue resolves, and then try to narrow the conflict down from there. I'll assign this to Nat and he can close it if he doesn't have anything else to add to my response.
Oh, installing the linter package was the only way to get diagnostics to work after the last update (nuclide did not provide a linter anymore that could be consumed by the linters). Haven't reported that yet. I'll try to separate the issues and report any other tomorrow.
@johnislarry I disabled all packages but nuclide and it's still happening. Are you sure you used the current atom-beta?
@despairblue I'm able to reproduce this on Atom Beta v1.8.0-beta2. I will take a look.
@despairblue Can you see what the value of NODE_ENV is in your default environment? Try running NODE_ENV=production atom-beta
. I can reproduce this if I run with no NODE_ENV set because it's letting React run in dev mode. I haven't tracked down what in React is breaking, but running in production mode seems to prevent this issue.
NODE_ENV
is not defined in my shell. Atom sets it to production
on first start. So here's the culprit:
A new feature in Atom 1.8.0 is that atom overwrites the env vars when you start it from the shell with the ones that are present in the shell. What happens:
That's not a problem usually. Most of the time you actually want things like PATH
to update.
In my opinion react should run in production mode unless NODE_ENV=development
and not run in development mode unless NODE_ENV=production
. It just seems too common that NODE_ENV is not set in an interactive shell. On the other hand: Why should react care about this specific use case? Most of the time it runs in a web browser where no one is overwriting process.env (which is probably set by webpack oder browserify).
Just for clarification, there seems to be a bug within react that produces theses errors, but fixing this is not fixing the underlying issue. Using atom
from the command line while Atom is already open throws react in development mode (unless you export NODE_ENV=production
), thus slowing down Atom as a whole. Not sure who's responsible for a fix in this case 😕
@despairblue One solution I've discussed with @zertosh is to ship Nuclide with the production/minified version of React that does not include the environment checks. Nuclide needs to eliminate 'react' as a top-level dependency, and then we can make the switch. The NODE_ENV
will behave like apparently is desired in Atom v1.8, but it will no longer affect Nuclide's React.
@ssorallen sounds like a plan! Any ETA on this?
I took another look at this and I remembered the original problem with the minified version. It's react-dom
and friends. But I think that if we use the dist version of react
and react-dom
loaded at the same time, we're ok. I have to test this. The other issue is with addons like the pure-render-mixin
. We're going to end up with duplicate code loaded, but I think it's minimal.
[Enter steps to reproduce below:]
atom-beta some_dir
atom-beta some_file
Ignore the errors in the beginning.
Atom Version: 1.8.0-beta2 System: Mac OS X 10.11.3 Thrown From: nuclide package, v0.130.0
Stack Trace
Uncaught TypeError: Cannot read property 'null' of undefined
Commands
Config
Installed Packages