facebook/create-react-app

Last call for Create React App v2

Timer opened this issue Β· 144 comments

Timer commented

Hi everyone! We just released what we hope to be the last beta before v2 is marked stable and tagged latest on npm tomorrow.

Please try it as soon as possible and let us know if you run into any issues!

Create new application:

$ npx create-react-app@next --scripts-version=@next test-next

Upgrade existing:

$ npm install react-scripts@next --save
$ # or
$ yarn add react-scripts@next

Here's a draft of the release notes:

Create React App v2.0.1

New Features

  1. Updated tooling: Babel 7, webpack 4, Jest 23
  2. Packages using new JavaScript features in node_modules now work
  3. Automatic vendor bundles and long term caching
  4. CSS Modules
  5. Sass Support
  6. SVGs as React Components
  7. Babel Macros
  8. Targetable CSS support, with automatic polyfills and prefixing

Migrating from 1.1.15 to 2.0.1

Inside any created project that has not been ejected, run:

$ npm install --save --save-exact react-scripts@2.0.1
$ # or
$ yarn add --exact react-scripts@2.0.1

Next, follow the migration instructions below that are relevant to you.

You may no longer code split with require.ensure()

We previously allowed code splitting with a webpack-specific directive, require.ensure(). It is now disabled in favor of import().

To switch to import(), follow the examples below:

Single Module

require.ensure(['module-a'], function() {
  var a = require('module-a');
  // ...
});
    
// Replace with:
import('module-a').then(a => {
  // ...
});

Multiple Module

require.ensure(['module-a', 'module-b'], function() {
  var a = require('module-a');
  var b = require('module-b');
  // ...
});
    
// Replace with:
Promise.all([import('module-a'), import('module-b')]).then(([a, b]) => {
  // ...
});

The default Jest environment was changed to jsdom

Look at the test entry in the scripts section of your package.json.
Here's a table how to change it from "before" and "after", depending on what you have there:

1.x (if you have this...) 2.x (...change it to this!)
react-scripts test --env=jsdom react-scripts test
react-scripts test react-scripts test --env=node

.mjs file extension support was removed

Change the extension of any files in your project using .mjs to just .js.

It was removed because of inconsistent support from underlying tools. We will add it back after it stops being experimental, and Jest gets built-in support for it.

Move advanced proxy configuration to src/setupProxy.js

This change is only required for individuals who used the advanced proxy configuration in v1.

To check if action is required, look for the proxy key in package.json. Then, follow the table below.

  1. I couldn't find a proxy key in package.json
    • No action is required!
  2. The value of proxy is a string (e.g. http://localhost:5000)
    • No action is required!
  3. The value of proxy is an object
    • Follow the migration instructions below.

If your proxy is an object, that means you are using the advanced proxy configuration.

Again, if your proxy field is a string, e.g. http://localhost:5000, you do not need to do anything. This feature is still supported and has the same behavior.

First, install http-proxy-middleware using npm or Yarn:

$ npm install http-proxy-middleware --save
$ # or
$ yarn add http-proxy-middleware

Next, create src/setupProxy.js and place the following contents in it:

const proxy = require('http-proxy-middleware')
    
module.exports = function(app) {
  // ...
}

Now, migrate each entry in your proxy object one by one, e.g.:

"proxy": {
  "/api": {
    "target": "http://localhost:5000/"
    },
  "/*.svg": {
    "target": "http://localhost:5000/"
  }
}

Place entries into src/setupProxy.js like so:

const proxy = require('http-proxy-middleware')
 
module.exports = function(app) {
  app.use(proxy('/api', { target: 'http://localhost:5000/' }))
  app.use(proxy('/*.svg', { target: 'http://localhost:5000/' }))
}

You can also use completely custom logic there now! This wasn't possible before.

Internet Explorer is no longer supported by default (but you can opt in!)

We have dropped default support for Internet Explorer 9, 10, and 11. If you still need to support these browsers, follow the instructions below.

First, install react-app-polyfill:

$ npm install react-app-polyfill --save
$ # or
$ yarn add react-app-polyfill

Next, place one of the following lines at the very top of src/index.js:

import 'react-app-polyfill/ie9'; // For IE 9-11 support
import 'react-app-polyfill/ie11'; // For IE 11 support

You can read more about these polyfills here.

The behavior of a CommonJS import() has changed

Webpack 4 changed the behavior of import() to be closer in line with the specification.

Previously, importing a CommonJS module did not require you specify the default export. In most cases, this is now required.
If you see errors in your application about ... is not a function, you likely need to update your dynamic import, e.g.:

const throttle = await import("lodash/throttle");
// replace with
const throttle = await import("lodash/throttle").then(m => m.default);

Anything missing?

This was a large release, and we might have missed something.

Please file an issue and we will try to help.

Migrating from 2.0.0-next.xyz

If you used 2.x alphas, please follow these instructions.

Detailed Changelog

>> TODO <<

I'm a bit late to the party. What do you mean with "node_modules are now compiled"?

I reworded to

Packages using new JavaScript features in node_modules now work

Does this make more sense?

I'm a bit late to the party. What dou you mean with "node_modules are now compiled"?

node_modules bundled with the app?

Thanks @gaearon, I was about to ask the same thing ^.^

I don't think I've ever needed it, but I guess it's nice it's there. Maybe this'll help build proper "goto definition" functionality, right now it keeps jumping to compiled js, and it's a mess.

Does this make more sense?

Yes. Thanks Dan!

I don't think I've ever needed it, but I guess it's nice it's there. Maybe this'll help build proper "goto definition" functionality, right now it keeps jumping to compiled js, and it's a mess.

I think there is some kind of misunderstanding here.

Previously, if somebody published a package that used newer syntax like const, and you imported that package, your app wouldn't build. We've had dozens of issues filed about this. See all issues linked from #1125. Now it will work.

Have an issue with @next:

When specified, "proxy" in package.json must be a string.
Instead, the type of "proxy" was "object".
Either remove "proxy" from package.json, or make it a string.

Actually, there was pretty extensive amount of options for proxy, are they all gone? With target, pathRewrite etc.
I used them on alpha as well.

Timer commented

@Z-AX this is not a bug -- we removed the proxy options. Please read the migration instructions above. πŸ˜„

Good job everyone working on wrapping up the 2.0 release! Thanks for your efforts!

Just tried here. It works. One question:
image

Why it says 1 instead of vendor? I guess that's the vendor bundle.
What if I have async routes and don't want to name them? Can I customize the vendor bundle name?

@Timer I don't see it in docs right here and it was working with the most recent alpha.
How should we migrate now without proxy? Why even it was removed? Very helpful for dev envs.

Edit: see it in Roadmap, don't see new docs on this.

iansu commented

@Z-AX You can now provide a custom express middleware function as a proxy: #5073. This should give you complete control over the proxy.

Are you planning on getting the typescript PR in or will that come in a minor update post 2.0 release?

Timer commented

@Z-AX added the preliminary docs here: 54323f0

The migration instructions above explain exactly how to migrate in the mean time.

pi0 commented

@Timer @gaearon Big changes! 🍷 Would you please point to the PR that enables babel for node_modules?

Have an errors when using flow in node_modules packages (using yarn workspace)

Timer commented

@pi0 #3776


@meafmira support for workspaces was dropped. Please see the migration instructions (we know they're not great, but we'll be improving them).

@Timer thanks, everything seems working.
But +1 to @zaguiini about file naming. I liked vendors more, now just have 2 chunks :)

Btw, is it something on my side that chunk 1 has content like this? As I can remember, always had this one on build, for maybe a year or so: (window.webpackJsonp=window.webpackJsonp||[]).push([[1],{1024:function(n,w,o){}}]);.

Have errors when using flow in node_modules packages and socket.io

Timer commented

Please file an issue with more details @sumitsg10 and a reproducible demo.

@Z-AX naming is pretty arbitrary and actually caused really bad behavior for larger apps. I don't think anyone but you (the developer) will ever notice. :-)

I don't think it's expected for Flow to work inside node_modules. We only compile standard JavaScript features inside node_modules. This is an intentional design choice to avoid the churn when proposals change, or new versions of Babel come out. You can ask React Native users about how Babel 7 upgrade went for them.

Timer commented

@lixiaoyan see the above message from @gaearon, the same reasoning applies

naming is pretty arbitrary and actually caused really bad behavior for larger apps. I don't think anyone but you (the developer) will ever notice. :-)

Yup, main is also "pretty arbitrary". Lots of people use vendor as their vendor bundle.
main's also a convention. Why not drop main too? See the point?

Timer commented

We make no guarantee that a chunk only contains node_modules, as it could be a mix of node_modules and app code.

You can read #4977, #4633, #4632 and a few others to learn why putting all of node_modules into a vendor chunk is a bad idea.

Feel free to open an issue with webpack to change the default name of the main chunk to a number.

@Timer Here are two problems with Jest & Babel:

  1. Jest doesn't use Babel to compile node_modules.
  2. Babel doesn't transform es modules to commonjs modules for files inside node_modules in test env (modules: false disable module transform).

which causes:

  1. Third-party modules that only provide es module files will cause syntax error during test.

So we may need to:

  1. Write a custom transform like this for Jest to compile node_modules with different Babel presets.
  2. Config modules: 'commonjs' for @babel/preset-env in test env.

It will make the transform behavior between Jest and Webpack more consistent.

(ES Module is standard JavaScript feature)

Upgraded an react-scripts@1.1.4 app with ~16kloc of React related code and everything was nearly painless:

  1. Had to upgrade eslint dependency to @^5. The error message for this was long but awesome!
  2. Due to some jest related changes a single test with lots of mocking now hangs and snapshots that use jest.mock() failed: no biggie
  3. On the first run the package prompted to add recommended browserlist settings to package.json, cool!
  4. CRA@2 caught a deleted re-export and threw, which CRA@1 just let by as undefined, πŸ’ƒ
  5. Bundle size down by 6.25%, which is nice
  6. Warm build times decreased by 51%, N-O-I-C-E

I don't think I've ever needed it, but I guess it's nice it's there. Maybe this'll help build proper "goto definition" functionality, right now it keeps jumping to compiled js, and it's a mess.

I think there is some kind of misunderstanding here.

Previously, if somebody published a package that used newer syntax like const, and you imported that package, your app wouldn't build. We've had dozens of issues filed about this. See all issues linked from #1125. Now it will work.

You're absolutely right! I personally have never had this happen, because most packages seem to come pre-transpiled =)

@Timer Another problem: Babel config may be overridden by a babel.config.js file, option babelrc: false is not enough to prevent config overwritten, setting option configFile: false is needed.

Timer commented

Nice catch, @lixiaoyan! Can you please send a PR disabling this?

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...

yarn add v1.9.4
info No lockfile found.
[1/4] Resolving packages...
error Couldn't find package "@xtuc/long@4.2.1" required by "@webassemblyjs/wast-parser@1.7.6" on the "npm" registry.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
Error: Couldn't find package "@xtuc/long@4.2.1" required by "@webassemblyjs/leb128@1.7.6" on the "npm" registry.
    at MessageError.ExtendableBuiltin (C:\Program Files (x86)\Yarn\lib\cli.js:243:66)
    at new MessageError (C:\Program Files (x86)\Yarn\lib\cli.js:272:123)
    at PackageRequest.<anonymous> (C:\Program Files (x86)\Yarn\lib\cli.js:38988:17)
    at Generator.throw (<anonymous>)
    at step (C:\Program Files (x86)\Yarn\lib\cli.js:92:30)
    at C:\Program Files (x86)\Yarn\lib\cli.js:105:13
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
Error: Couldn't find package "@xtuc/long@4.2.1" required by "@webassemblyjs/wast-printer@1.7.6" on the "npm" registry.
    at MessageError.ExtendableBuiltin (C:\Program Files (x86)\Yarn\lib\cli.js:243:66)
    at new MessageError (C:\Program Files (x86)\Yarn\lib\cli.js:272:123)
    at PackageRequest.<anonymous> (C:\Program Files (x86)\Yarn\lib\cli.js:38988:17)
    at Generator.throw (<anonymous>)
    at step (C:\Program Files (x86)\Yarn\lib\cli.js:92:30)
    at C:\Program Files (x86)\Yarn\lib\cli.js:105:13
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
Error: Couldn't find package "@xtuc/ieee754@^1.2.0" required by "@webassemblyjs/ieee754@1.7.6" on the "npm" registry.
    at MessageError.ExtendableBuiltin (C:\Program Files (x86)\Yarn\lib\cli.js:243:66)
    at new MessageError (C:\Program Files (x86)\Yarn\lib\cli.js:272:123)
    at PackageRequest.<anonymous> (C:\Program Files (x86)\Yarn\lib\cli.js:38988:17)
    at Generator.throw (<anonymous>)
    at step (C:\Program Files (x86)\Yarn\lib\cli.js:92:30)
    at C:\Program Files (x86)\Yarn\lib\cli.js:105:13
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

Aborting installation.
  yarnpkg add --exact react react-dom react-scripts@next --cwd C:\Users\s5201911\Desktop\test-next has failed.

Deleting generated file... package.json
Deleting test-next/ from C:\Users\s5201911\Desktop
Done.
ai commented

Targetable CSS support

Did CRA uses Browserslist only for Autoprefixer?

Should we change ChangeLog or CRA’s Babel config?

Timer commented

@ai browserslist is only used for CSS. There were too many edge cases where browser target support for babel did not "just work", unfortunately. This is by no fault browserslist's, it seemed to be more of an issue with preset-env.

I'm getting this error when trying to build,

Module build failed: Cannot read property 'type' of undefined
    at Array.some (<anonymous>)
    at Array.forEach (<anonymous>)

No file or line number is printed πŸ˜• and my code doesn't have .some in it. Sadly it's a private repo so I can't share the code.

Timer commented

@holloway Can you please file a new issue with a reproducing project, please?

ai commented

@Timer

browserslist is only used for CSS. There were too many edge cases where browser target support for babel did not "just work", unfortunately. This is by no fault browserslist's, it seemed to be more of an issue with preset-env.

Can you show edge case examples? I will try to find people who will fix the source of the problem.

Did a fresh install and it works a charm πŸ‘

Anyone has an idea of how to make babel-plugin-react-css-modules work without ejecting? I've read that this could be accomplished with Babel Macros but I have no idea how to write one for this.

The idea is to have styleName work without ejecting, as well as gaining all the performance benefits while not having to eject.

Timer commented

You'd need a macro, @davidalejandroaguilar.

I updated one of our apps from 1.1.1 to next and it worked pretty well. Few jsx-a11y warnings showed up (easy to fix), but start, test and build scripts were without errors. πŸŽ‰

@Timer I don't know how to write plugins/macros, if this is the case, do I need to stick with having to import styles as an object and using className?

I'm still concerned about that performance regression that Webpack 4 has. I mentioned it here in connection to CRA's dependence on Webpack 4.

I'm not sure whether sokra's recommendation there (to use the terser-webpack-plugin if possible) will work without ejecting from CRA, but it seems like something could/should be mentioned somewhere. I checked for any mention in the branch and didn't see any.

I know a number of devs have chewed up a lot of time chasing down this mysterious issue. Anyone using CRA and Font Awesome v5 (as well as any other libraries that have similar layouts as ours that would hit this perf regression) may soon find themselves joining in that debugging party.

Timer commented

Hmm, we can definitely switch back to uglify if it's more performant.

We could also profile Terser a bit and see if there's low hanging fruit.

I too have this question from @stramel above:

Are you planning on getting the typescript PR in or will that come in a minor update post 2.0 release?

Given that #4837 is not yet closed, and not yet even building on CI, I assume the answer is not now. But I hope not too long from now πŸ™ πŸ™ πŸ™

BTW, great work! This looks amazing regardless.

In v1 I could use decorators by using react-app-rewired, is it still the case with v2?

Gpx commented

I'm getting this error when running my tests, any clue what it could be?

 FAIL  src/app/any_of_the_test_file.test.js
  ● Test suite failed to run

    ReferenceError: self is not defined

      at node_modules/react-app-polyfill/node_modules/whatwg-fetch/dist/fetch.umd.js:8:40
      at Object.<anonymous>.support.searchParams (node_modules/react-app-polyfill/node_modules/whatwg-fetch/dist/fetch.umd.js:2:66)
      at Object.<anonymous> (node_modules/react-app-polyfill/node_modules/whatwg-fetch/dist/fetch.umd.js:5:2)
      at Object.<anonymous> (node_modules/react-app-polyfill/jsdom.js:10:1)

This happens for all tests.

I've changed my test command from react-scripts test --env=jsdom to react-scripts test --env=node.

If I run the tests with the jsdom version I get all kinds of errors, like TypeError: Cannot read property 'bind' of undefined on values that are not undefined.

@Gpx

If you previously disabled jsdom, you may have removed the --env=jsdom flag. Make sure your test script in package.json contains the --env=node flag

That means:

1.0 2.0
react-scripts test --env=jsdom react-scripts test
react-scripts test react-scripts test --env=node

So you just need to remove --env=jsdom but not add --env=node.

Gpx commented

@lixiaoyan thanks, I didn't understand it.

I modified it and now the error is this

Requires Babel "^7.0.0-0", but was loaded with "6.26.0". If you are sure you have a compatible version of @babel/core, it is likely that something in your build process is loading the wrong version. Inspect the stack trace of this error to look for the first entry that doesn't mention "@babel/core" or "babel-core" to see what is calling Babel. (While processing preset: "/node_modules/babel-preset-react-app/index.js")

I followed this comment jestjs/jest#6913 (comment) and that fixed it.

Now I'm having a lot of errors about TypeError: Cannot read property 'bind' of undefined

after existing project update when starting the app I get an error

./node_modules/apollo-link-state/lib/utils.js 27:51-56
  'graphql' does not contain an export named 'print'.

all dependencies are at their latest versions and graphql does contain export named print and it worked fine before the cra update πŸ€”

@davidalekna

all dependencies are at their latest versions and graphql does contain export named print and it worked fine before the cra update

Provide a reproducing project please?

@Gpx

I followed this comment jestjs/jest#6913 (comment) and that fixed it.

It’s not clear how you β€œfollowed” it because this comment didn’t contain any instructions. If you installed some package manually you probably further broke your setup.

Please revert your change (whatever it was), remove node_modules, reinstall them, and then file a new issue with your project (or a small reproducing case).

@binarylogician

In v1 I could use decorators by using react-app-rewired, is it still the case with v2?

The current maintainer of rewired is not planning to support 2.x but maybe somebody else wants to step in?

That said there’s a good reason we didn’t (and still don’t) support decorators. Are you aware that the specification changed and the old syntax and API is never going to be a standard? Now there’s going to be churn for everybody who used old decorators. We shielded our users from this by not allowing them. You might want to reconsider using decorators until the transform is more stable and stops changing.

@gaearon I've created a reproduction and it seems to work... It might be specific to my use case as I'm using react-app-rewired to transpile "shared" directory which is outside of src... As I've noticed react-app-rewired will not support react-scripts@2... I was wondering if there is another way of achieving this? (without ejecting...)

Thanks

@gaearon I'm experiencing the same bug as @davidalekna

I created a project in which you can reproduce it: https://github.com/albertorestifo/create-react-app-apollo-bug

See this commit for all the changes I did on top of the out-of-the-box react app: https://github.com/albertorestifo/create-react-app-apollo-bug/commit/efa5cc384b913381b5740e6ad14e91009041a2b2

@davidalekna Existing rewires won't work with 2.x. Sorry we didn't make this clear. That's the kind of risk you were taking when you added rewires. AFAIK the project maintainer is not planning to support 2.x but maybe somebody else will take over it.

It might be specific to my use case as I'm using react-app-rewired to transpile "shared" directory which is outside of src..

We'll definitely want to figure out some way of doing it but you're right it's not yet supported. Maybe later in 2.x.

@albertorestifo Appreciated. We'll take a look.

@davidalekna should be easy to modify react-app-rewire to work with 2.0, we started work on migrating back before the summer but neither me or the original author works on related projects atm therefor have incentive to fix it right away. you can always submit a PR :)

In the README it still states on line 1002: ... Create React App includes a polyfill for fetch() so you can use it without worrying about the browser support. I do however believe all polyfill have been removed, hence this sentence should also be updated/removed.

@gaearon

We could also profile Terser a bit and see if there's low hanging fruit.

I made a fairly minimal demo repo of the relevant build scenario. I'm delighted to find that CRA v2 is already configured to use terser-webpack-plugin. So the build is quick, as expected.

Awesome. No more concern here from me.

Went from 1.1.5 > 2.0.0 and got:

./node_modules/react-event-listener/dist/react-event-listener.cjs.js
Module not found: Can't resolve '@babel/runtime/helpers/builtin/classCallCheck' in 'C:\App\node_modules\react-event-listener\dist' 

My package.json: https://gist.github.com/henkvhest/1fdf2d5a65b98ba76379f999f354211d

@henkvhest Thanks, I added this to #5116 which seems similar.

@ArmanNisch Good point. We'll need to do another pass at README and User Guide after releasing.

@gaearon any announcement in changelog and here about: #4169?

@frederikhors Yes, documenting it is in the todos

@Timer I just re-read your comment and realized I'd misunderstood:

Hmm, we can definitely switch back to uglify if it's more performant.

My hope has been to use terser for better performance and NOT uglify. I had wrongly assumed that CRA was still using uglify. I hadn't realized that CRA had already moved to terser. That wasn't the case last I checked. Anyway, I posted a demo above that demonstrates that, with terser in CRA 2.0.0, the relevant scenario builds great. So we're all good here.

I see there's now an inline script added in index.html, which breaks my CSP. Is there a recommended way to deal with this?

@Timer

browserslist is only used for CSS. There were too many edge cases where browser target support for babel did not "just work", unfortunately. This is by no fault browserslist's, it seemed to be more of an issue with preset-env.

Can you show edge case examples? I will try to find people who will fix the source of the problem.

I can help too!

I see there's now an inline script added in index.html, which breaks my CSP. Is there a recommended way to deal with this?

This is interesting, can you tell a bit more? Are all inline scripts disallowed in your environment?

I wasn't allowing any inline scripts previously. Adding 'unsafe-inline' to my script-src gets it working again, but I'd rather be more restrictive.

@ai browserslist is only used for CSS. There were too many edge cases where browser target support for babel did not "just work", unfortunately. This is by no fault browserslist's, it seemed to be more of an issue with preset-env.

@Timer just to echo @ai, happy to help prioritize fixing any issues in preset-env.

@caedmon The reason we put it there is because it's better for long term caching. This is a small snippet so it would be a shame to send it as a separate request. And attaching it to some other chunk would constantly invalidate it. I think it's a reasonable compromise. Maybe we can provide an opt-out.

@gaearon I understand the motivation for inlining this code. Would there be a way to configure a nonce to add to the script which could then
be used in the CSP?

Can you raise a separate issue with the proposal please?

Can you raise a separate issue with the proposal please?

#5144

tried to run the migration commands but nothing really happened apart of react-scripts was updated to version 2 in my package.json.

@stramel: Are you planning on getting the typescript PR in?
@gnapse: Given that #4837 is not yet closed, and not yet even building on CI, I assume the answer is not now. But I hope not too long from now πŸ™πŸ™πŸ™

TypeScript support #4837 is ready to be merged, in my opinion. Build is now passing.

It didn’t make it into 2.0.0 but hopefully it will be added soon :)

jt3k commented

where is my hot reload out of the box?

ligaz commented

Removing the mjs support yields incompatibility with latest versions of graphql-js library (and iterall as well), because the lib export itself as module with .mjs extension. That indirectly affects a couple of Apollo related libraries as well.

A way to workaround this in your projects is to downgrade to version 0.13.0 of graphql and lock the version of iterall to 1.1.4 via yarn's resolutions.

it only has hot reload, not hmr :/

hey guys there is another compilation error on react-powerplug

Failed to compile

./node_modules/react-powerplug/dist/react-powerplug.esm.js
Module not found: Can't resolve '@babel/runtime/helpers/builtin/es6/assertThisInitialized' in '.../node_modules/react-powerplug/dist'

also can NODE_ENV be staging?

@jt3k

where is my hot reload out of the box?

A few more things need to happen but I think we’ll have it by December.

@davidalekna

hey guys there is another compilation error on react-powerplug

It’s fixed in master. We’ll cut a patch soon.

Timer commented

react-scripts@2.0.1 is out. Everyone, please upgrade your dependencies and see if your issues have been fixes (or if new ones arised)!

Error: Received malformed response from registry for undefined. The registry may be down.

Projects adf$ npx create-react-app@next --scripts-version=@next test-next
npx: installed 63 in 14.711s

Creating a new React app in /Users/adf/Projects/test-next.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...

yarn add v1.3.2
info No lockfile found.
[1/4] πŸ” Resolving packages...
error Received malformed response from registry for undefined. The registry may be down.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
Error: Received malformed response from registry for undefined. The registry may be down.
at /usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:48907:15
at Generator.next ()
at step (/usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:92:30)
at /usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:110:14
at new Promise ()
at new F (/usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:29389:28)
at /usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:89:12
at Function.findVersionInRegistryResponse (/usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:48946:7)
at /usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:48963:28
at Generator.next ()

Aborting installation.
yarnpkg add --exact react react-dom react-scripts@next --cwd /Users/adf/Projects/test-next has failed.

Deleting generated file... package.json
Deleting test-next/ from /Users/adf/Projects
Done.

Timer commented

Update your Yarn version and try again.

This is more of an npm issue, but just for awareness:
Running npm upgrade react-scripts@next --save didn't do anything for me.
I had to run npm install react-scripts@next --save

Timer commented

Odd, I changed the command. Thanks for the heads up!

how about react-scripts-ts ?? is there any upgrade ??

@soufDev We aren't the maintainers of that package. It's maintained by the community. We might add TS support later in 2.x, but not in 2.0.

Just tried v2.0.1, works perfectly. When will v2 be tagged latest btw?

Thanks.

Today probably.

So... do I have to add babel config or something now, to make it compile node modules properly? I still have it in dependent module itself (used before to build it).

With react-scripts start I get something like this in dependent module which is a git+https://...:

Failed to compile.

./node_modules/my-git-node-module/components/ExternalMenuItem.js
Syntax error: Unexpected token (23:4)

  21 | const ExternalMenuItem = ({ title, classes }) => {
  22 |   return (
> 23 |     <span className={classes.wrapper} >
     |     ^

For react-scripts build getting pretty much the same, JSX is not parsed:

Creating an optimized production build...
Failed to compile.

./node_modules/my-git-node-module/components/HelpIcon.js
Syntax error: Unexpected token (56:6)

  54 | 
  55 |     return (
> 56 |       <Tooltip
     |       ^

I do see a bit strange output in the production build. Before the update I had only chunks that I named myself but now some chunks show up labeled from 0 to 7. Anyone else encountered this aswell? It's not blocking me in any way, the application still functions the same as before.

image

Timer commented

What version did you upgrade from, @henkvhest?

@Z-AX

So... do I have to add babel config or something now to make it compile node modules? I have it in dependent module itself (used before to build it).

We only compile valid JavaScript syntax in node_modules. JSX is not valid JavaScript. You are using JSX there.

The reason we've taken this stance is because compiling non-standard syntax tightly couples libraries to build tools. For example, if JSX changes and Babel 8 comes out with those changes, suddenly all libraries using JSX internally wouldn't work anymore. You can fix your code but fixing dependencies takes a lot more coordinated effort. And people using Babel 7 (in this example) wouldn't appreciate their code breaking either. So every library would be forced to release a new major version, and possibly maintain both for a long time.

It's also hard to draw a line once you allow experimental things. Most people will want to use not just JSX, but also experimental transforms like class properties. Or decorators. Now we have to argue with every library maintainer about which transforms we want to support, and which we don't. But all of these transforms tend to change until standardized. It already happened many times, e.g. Babel 7 changed the semantics of class properties a little bit. It will happen again.

So say Babel 8 comes out with different class properties behavior. Now you have to vet all libraries you depend on to check if they expect old or new behavior. Nobody can upgrade to the next CRA/Babel because they're locked into the experimental syntax their dependencies (including transitive ones) assume. You can see how this exact situation played out with Babel 7 upgrade in the React Native community. It caused months of pain for RN users, and it's still an ongoing problem.

This is why we don't compile non-standard syntax in node_modules.

What version did you upgrade from, @henkvhest?

From 1.1.5 to 2.0.1

I'm using PreloadWebpackPlugin, after migrate from 6.0.0-next.a671462c to 6.0.1 this error arise:

Syntax error: Unable to tap into the HtmlWebpackPlugin's callbacks. Make sure to list PreloadPlugin at some point after HtmlWebpackPlugin in webpack's plugins array.

This plugin is after HtmlWebpackPlugin:

new PreloadWebpackPlugin({
rel: "prefetch",
include: "allAssets",
})

I can reproduce it in a new project using CRA 2.0:

"html-webpack-plugin": "4.0.0-beta.1",
"preload-webpack-plugin": "3.0.0-beta.2",
"react-dev-utils": "6.0.1",

@djgrant That's not an issue with CRA 2 per se. It's expected that react-dev-utils changes more often with the needs of the project. You can create a new app and eject it to see how it's wired up. Then you can figure out how to make these two plugins working again.

@gaearon sounds reasonable, but strange same time. We're talking about react scripts, so they are intended to work with React code, which basically has JSX in all of our projects.

We have a situation now, for example, where projects reuse the core library of components, helpers etc. Components are in JSX. As our main apps. As CRA created app example. So, what I was expecting is react-scripts will compile everything same way, so we won't have any kind of customizations in build process, everything will use same browserslist etc.

Is there an option to "turn on" JSX processing in node modules?

The problem isn't with just JSX, it's with all the other experimental transforms. But JSX is a part of it too.

We're talking about react scripts, so they are intended to work with React code, which basically has JSX in all of our projects.

And your application code builds just fine. We're only talking about third-party dependencies.

We have a situation now, for example, where projects reuse the core library of components, helpers etc. Components are in JSX. As our main apps. As CRA created app example. So, what I was expecting is react-scripts will compile everything same way, so we won't have any kind of customizations in build process, everything will use same browserslist etc.

I understand this very well. Monorepo support was supposed to help with this but we removed it from 2.0 because it was half-baked. We want to allow something like this later, but we need to figure out for it to be safe and opt-in without creating problems for the ecosystem.

Syntax error: Unable to tap into the HtmlWebpackPlugin's callbacks

The upcoming html-webpack-plugin v4 (of which 4.0.0-beta.1 is included in CRA 2) has changed the name of several hooks, meaning that many plugins will need updates to remain compatible:
jantimon/html-webpack-plugin#953 (comment)

To get the ball rolling for this case I've filed GoogleChromeLabs/preload-webpack-plugin#79.