Create-react-app: Public Beta Testing of [email protected]

[gaearon]

---

Known Issues:

• None (please report!)

Updates:

• Published the first canary.
• Published another canary that fixes the path issue and disables require.ensure() warning.
• Published another canary that re-enables parsing of require.ensure().
• Published a canary with more legible colors on Windows and port detection fixes
• Published a canary with Jest fixes, stricter module resolution, Uglify fix, and more consistent overlay styling
• Published a canary with fixed npm package, more visual fixes to overlays, better build messages, and smaller post eject code size
• Final call for testing: Published the last canary with IE fixes.

---

Today I invite you to help us beta test [email protected] for a few days before the public release.
It used to be called 0.10 but we figured there’s enough improvements to make it 1.0.

To create a new app with it, run:

create-react-app my-app --scripts-version react-scripts@canary

To upgrade an existing app, replace "react-scripts": "0.9.5" in your package.json with:

```
"react-scripts": "canary"
````

and run npm install (or yarn).

There is no changelog yet, but you can open the milestone to get a sense of included changes.

A few highlights:

• Webpack 2 (https://github.com/facebookincubator/create-react-app/pull/1291)
• Jest 20 (https://github.com/facebookincubator/create-react-app/pull/1614, https://github.com/facebookincubator/create-react-app/pull/2171)
• Code splitting with dynamic import() (https://github.com/facebookincubator/create-react-app/pull/1538)
• Runtime overlay for uncaught errors (https://github.com/facebookincubator/create-react-app/pull/1101)
• Local and environment-specific env files (https://github.com/facebookincubator/create-react-app/pull/1344)
• Multiple proxies (https://github.com/facebookincubator/create-react-app/pull/1790)
• Accidental usage of non-obvious globals is forbidden (https://github.com/facebookincubator/create-react-app/pull/2130)
• Some Jest options are overridable (https://github.com/facebookincubator/create-react-app/pull/1830)
• Nicer warning and error output (https://github.com/facebookincubator/create-react-app/pull/2120, https://github.com/facebookincubator/create-react-app/pull/2125, https://github.com/facebookincubator/create-react-app/pull/2161)
• You can use a Node script as a BROWSER variable (https://github.com/facebookincubator/create-react-app/pull/1590)
• Only image assets are inlined (https://github.com/facebookincubator/create-react-app/pull/1305)
• Only tests in src run now (https://github.com/facebookincubator/create-react-app/pull/1808)
• Some flexbox bugs are autofixed, and support for 2009 spec is dropped (https://github.com/facebookincubator/create-react-app/pull/1771)
• Editing the public folder refreshes the page (https://github.com/facebookincubator/create-react-app/pull/1546)

There are a few more changes we plan to get into 1.0.0, but this should be enough the first public testing.

Please report any issues you bump into in this thread. We want this release to be as solid as possible, even though it’s unlikely we’ll keep it unreleased for much longer.

Big thanks to all the contributors. This will be our biggest release yet.

[RohovDmytro]

Testing. Compilation failed. Something is wrong with webpack.

Will try to get more info.

What I've tried to solve

• run yarn upgrade. This got me into:
  ````
  Failed to compile.

./~/react-error-overlay/lib/utils/unmapper.js
Module not found: Can't resolve '/Users/dan/p/create-react-app/packages/babel-preset-react-app/node_modules/babel-runtime/regenerator' in '/[---------]/my-project/node_modules/react-error-overlay/lib/utils'
````

• removing node_modules and yarn.lock with fresh install did not help either.

[gaearon]

@rogovdm

Can you provide minimal project reproducing this?

[RohovDmytro]

@gaearon Please, notice /dan/p/ part in path. Something is clearly wrong. 😺

[gaearon]

Hmm yea that looks funny.

[gaearon]

Maybe something in my local Lerna setup got messed up. I'll try to republish from another laptop in an hour or two.

[micooz]

Same problem:

Failed to compile.

./~/react-error-overlay/lib/utils/unmapper.js
Module not found: Can't resolve '/Users/dan/p/create-react-app/packages/babel-preset-react-app/node_modules/babel-runtime/regenerator' in '/home/micooz/Projects/blinksocks-desktop/frontend/node_modules/react-error-overlay/lib/utils'

[gaearon]

Can you edit that file by hand for now to remove the absolute filename from it? Are there more such files?

[RohovDmytro]

@gaearon checked node_modules for /Users/dan pattern.

31 results in 9 files

Search results screenshot

[RohovDmytro]

All of .js files are about regenerator module.

[stepankuzmin]

Fixing path in react-error-overlay did the trick for me

[jamesmcallister]

I can confirm that dan is lurking my on pc as well 📦
I changed the imports from

import _regeneratorRuntime from '/Users/dan/p/create-react-app/packages/babel-preset-react-app/node_modules/babel-runtime/regenerator';

to

import _regeneratorRuntime from '../../../babel-runtime/regenerator';

seems to work now. start and build works

[bneumann]

Same problem here. Fixed by renaming my user to Dan :)
No actually @jamesmcallister is right. It is in the mapper, unmapper and getSourceMap file

[jamesmcallister]

@bneumann I agree changing my user name to Dan would have been easier!!

[RohovDmytro]

Pssss. It's a new feature they are working at headquarters. Hot User Replacement.

Changing logged user in OS without refreshing the tab page!

By any means — congratulations with this sweetest release. 😺 🔥

Also, did it slip thought travis? Maybe, need some checks there.

[gaearon]

This didn’t affect Travis because the build is done on the same machine so naturally the folder exists.

I think the fix is to remove the resolving of regenerator runtime in Babel preset configuration. (Or we could stop using our preset for the crash overlay.) I think we only needed that for npm 2 in the past.

[jamesmcallister]

@gaearon maybe its time to build in a VM which gets purly built for this task? like with Ansible.

[gaearon]

Maybe. IMO this kind of mistake is unlikely to bite us again once we fix this, but happy to take suggestions / PRs.

[ingro]

After fixing paths in react-error-overlay all is running fine without errors. However I'm using a lot of dynamic imports with require.ensure syntax which has been restricted now using eslint's no-restricted-properties rule. Converting all the dynamic imports from require.ensure to import results in a massive perf loss, the building time (even in development mode) is skyrocketing as noted in this webpack issue.

Maybe it's best to allow require.ensure until the performance of dynamic imports are improved by the webpack's core team?

[gaearon]

Converting all the dynamic imports from require.ensure to import results in a massive perf loss, the building time (even in development mode) is skyrocketing as noted in this webpack issue.

How much are we talking about?

[gaearon]

I expect https://github.com/facebookincubator/create-react-app/pull/2175 to resolve the issue with filepaths. Will wait for CI to pass and cut a new canary.

Thanks for feedback on dynamic import(). I agree that if it’s slow, we should hold off promoting it, and instead work with Webpack to fix it. Can you help them by providing a reproducing case?

[ingro]

I cannot be precise because cra don't return build time but like from 2 seconds with 0.9.5 to 10+ or even more with canary (I'm using like ~20 dynamic imports).

As for the reproducing case I'm not sure I can extract something useful since it's quite a complex project but I can try!

[gaearon]

Please do. I don't think it's feasible to fix unless somebody takes the time and prepares a good repro case.

[gaearon]

I published a new canary.

It should fix the path issue and should also disable the require.ensure() warning (since dynamic import performance needs to be fixed).

Can you please try it?
(Instructions for installing are the same, just run npm install again if you put canary in there.)

[nuwanc]

path issue is fixed now. i dont get that error

[ingro]

Can confirm that require.ensure works fine now, I also created a repo to reproduce the issue for the webpack team, hope it will be useful.

[deiucanta]

Just tested the latest release on my side project and everything works just fine.

I see you changed the design/colors for the error messages. Is there a way to get the dark theme back? Not that I don't like this one, I'm just curious if there is an option for that.

Also, any ETA on built-in HMR for React components?

[gaearon]

No, there is no option to change the theme, although the syntax screen is a bit unpolished now.
@bvaughn is working on making it better.

We made it light to align better with the runtime crash overlay, but there’s more design work to do.

Also, any ETA on built-in HMR for React components?

No ETA. But you can read https://github.com/gaearon/react-hot-boilerplate/issues/97#issuecomment-249862775 for the big plan.

[dwightwatson]

All appears to be working as expected on one of my side projects.

It does seems odd to me that tests in a root-level __test__ directory no longer run, I thought that was the default location for Jest. Is the new preference to just move it to src/__test__ instead?

[gaearon]

Yes, please do move it. It has always been documented that only tests inside src run, but we didn't enforce it by mistake. People complained about Jest finding “unintentional” tests before (e.g. integration tests that don’t use Jest) so we’re closing that.

[TheRobBrennan]

Sweet!! Is there a way to have 100% coverage out of the gate? Or is there a way to exclude index.js - and potentially other files - from negatively impacting the test coverage? It'd be great to see coverage on components we know are created/under test - and to ignore files that may not warrant the 100% coverage.

[stunaz]

I get get a new warning:
[eslint] Definition for rule 'jsx-a11y/alt-text' was not found (jsx-a11y/alt-text)

[gaearon]

@TheRobBrennan Yes, you can now specify custom collectCoverageFrom option in jest section of package.json.

@stunaz If you checked "Use global ESLint" in Atom settings please uncheck it.

[bdwain]

I found a super weird bug, and while I don't think it's specific to create-react-app, it's worth noting for anyone who wants to support chrome 51 because the upgrade to webpack 2 exposes it.

I filed it with uglify here because I think it's related to how webpack 2 uses it, but it could cause issues for people upgrading to this.

Basically, the bug causes String.split to misbehave (but only in chrome 51 and only if your app is minified). If a library ends up using string.split in a way that breaks, your app will break (for example, the humps js library broke for me)

[Timer]

@bdwain that's definitely a blocker -- can you please open a formal issue and we can tag it as such? Thanks!

[bdwain]

yup. ill do that.

[bdwain]

@Timer made #2199

[gaearon]

Published another canary with Jest fixes, stricter module resolution, Uglify fix, and more consistent overlay styling. Please give it a try!

[mvanlonden]

Upgraded scripts and ran into
```
yarn start v0.21.3
$ react-scripts start
module.js:472
throw err;
^

Error: Cannot find module 'react-dev-utils/ModuleScopePlugin'
at Function.Module._resolveFilename (module.js:470:15)
at Function.Module._load (module.js:418:25)
at Module.require (module.js:498:17)
at require (internal/module.js:20:19)
at Object. (/node_modules/react-scripts/config/webpack.config.dev.js:21:27)
at Module._compile (module.js:571:32)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:488:32)
at tryModuleLoad (module.js:447:12)
at Function.Module._load (module.js:439:3)
at Module.require (module.js:498:17)
at require (internal/module.js:20:19)
at Object. (/node_modules/react-scripts/scripts/start.js:36:16)
at Module._compile (module.js:571:32)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:488:32)
error Command failed with exit code 1.
````

[gaearon]

Yea.. Super weird it's not on npm because it's definitely in master, and in files in package.json too.

[gaearon]

Actually no, it's here: https://unpkg.com/[email protected]/ModuleScopePlugin.js.

Try deleting node_modules and running npm install?

[gaearon]

Looks like some it could be a Yarn bug? cc @bestander

[email protected] asks for

"react-dev-utils": "^1.0.0-alpha.c82c4f05",

but I see

[email protected]

installed instead.

Try running npm install [email protected] as temporary fix.

[Timer]

@gaearon could it be the ^, where e > c? Maybe we should pass the --exact flag to lerna.

Yikes, looks like semver just functions like this:

[cdaringe]

per the semver spec:

Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

therefore, e280254d is > c82c4f05, which makes some amount of sense. the hash is still treated like a version number, so long as everything preceding is a match.

[gaearon]

Huh. I guess Lerna --canary feature is a bit broken then.

[gaearon]

Yep, it’s completely broken. 😄
https://github.com/lerna/lerna/issues/277

I wish I knew that before.

[gaearon]

Published a new canary with fixed npm package, more visual fixes to overlays, better build messages, and smaller post eject code size.

Please give it a try! It’s close to a release candidate.

[mxstbr]

Been running a custom fork of (what used to be) 0.10 in production for a month or two now (ever since the webpack 2 PR) and haven't run into any bugs/issues yet!

[gaearon]

Just published an RC as the last canary.
Speak now or hold your peace 😄

[notrab]

Just ran an upgrade and everything went smoothly. Just deployed to production too, everything running fine 🤘

[kentcdodds]

The testing-workshop tests all passed without a hitch! And the app still looks perfect (both dev and prod versions)! 🚀 🚢

[RohovDmytro]

New canary caught me on some none-existed imported values. Fixing that led me to successfull deployment to prod!

[RohovDmytro]

Feedback.

````
./src/components/PageResume.js
Line 530: 'Wow' is not defined react/jsx-no-undef

Search for the rule keywords to learn more about each error.
````

«rule keywords» was confusing for me for 15 seconds.

Word «rule» is confusing. What rule? I am not aware of any rules. This project hides config complexity, so a novice may not get what this message about.

We can make «react/jsx-no-undef» clickable , but maybe it's to much 😺

[TheRobBrennan]

@gaearon This is awesome!!! Thank you for adding that. This is absolutely beautiful now:

[gaearon]

@rogovdm I agree, changed to just keywords. Ideally I’d like to make them clickable but I don’t want to force people to use Google.

[mbifulco]

Updating an existing project - this is working great for me so far. Thanks to you and your team, @gaearon!

[ffxsam]

I get get a new warning:
[eslint] Definition for rule 'jsx-a11y/alt-text' was not found (jsx-a11y/alt-text)

I get this warning now too, and can't figure out how to get rid of it. It's not documented in the README, and Googling around for this didn't turn up anything useful.

[gaearon]

Where do you get it? You have not specified your editor, plugin, whether you use global ESLint for it, etc.

[gaearon]

I'll close this issue since 1.0 is out but please file new ones if something is confusing!

[ffxsam]

Nuclide, latest version (of Atom as well). No global eslint installed.
BTW, I found the plugin & its documentation. Fixed it with the following in my .eslintrc:

  "rules": {
    "jsx-a11y/alt-text": "off",

[gaearon]

That's not the right fix, you're still running wrong versions of plugins. This silences this warning but you'll see more breakage in the future. I suggest fixing the root cause rather than symptoms.

Let's try this:

1. Ensure that in Atom ESLint settings you have "Use Global ESLint" turned off
2. Run npm install in your project (or yarn)
3. Quit Atom (ensure its process doesn't hang around)
4. Start Atom again

I think that should help but let me know if not, and we can debug more.

[ffxsam]

That did the trick! I noticed that .eslintrc changes would get recognized by closing a file and reopening it, but in this case, quitting Atom entirely was required.

[gaearon]

Yea. Since it loads rules into memory, their code sticks around in the require cache even after closing the file.

[slightly-askew]

Hi gaearon & all, I'm getting the following flow error in both Nuclide and VS Code. I've tried the above steps you recommended several times but no joy. Also tried deleting node_modules and reinstalling.

identifier ESLintContext Could not resolve name

Doesn't happen in React Scripts v0.9.x; only when upgrading to 1.0.2-3

In Nuclide 0.228.0:

• Linter is disabled
• linter-eslint 8.1.7 is enabled with _use global_ off

In VS Code 1.12.2:

• ESLint is enabled

Here are my .eslintrc and .flowconfig settings:

devDependancies:

"devDependencies": {
    "@kadira/storybook": "^2.21.0",
    "eslint-plugin-jsx-a11y": "^5.0.3",
    "flow-bin": "^0.42.0",
    "react-scripts": "^1.0.3",
    "stylelint": "^7.10.1",
    "stylelint-config-standard": "^16.0.0"
  },

Any suggestions much appreciated!

[gaearon]

The error is because Flow is trying to typecheck the ESLint plugin.
You probably want to add .*/eslint-plugin-jsx-a11y/.* to [ignore] in your .flowconfig.

[slightly-askew]

Ahh ok that worked, thanks very much :)

[zerubeus]

@gaearon I don't have global ESlint, and I'm using VSCode, and I have this warning in both when working locally and the Tarvic CI is breaking because of this same warning : Definition for rule 'jsx-a11y/alt-text' was not found jsx-a11y/alt-text, this occurred after updating to react-script 1.0.7

[gaearon]

@zerubeus The public testing has finished a long time ago so this is not an appropriate issue. Please file a new issue with an example project reproducing this. Thanks!