Update dependency react-scripts to v2 - autoclosed

[mend-for-git.832008.xyz]

This PR contains the following updates:

Package	Type	Update	Change
react-scripts (source)	devDependencies	major	^1.0.11 -> ^2.0.0
react-scripts (source)	dependencies	major	^1.1.4 -> ^2.0.0

By merging this PR, the issue #69 will be automatically resolved and closed:

Severity	CVSS Score	CVE
Critical	9.8	CVE-2018-1000620
Critical	9.8	CVE-2018-1000620
Critical	9.8	CVE-2018-13797
Critical	9.8	CVE-2018-16492
Critical	9.8	CVE-2020-28499
Critical	9.8	CVE-2021-23369
Critical	9.8	CVE-2021-23383
Critical	9.8	CVE-2021-3918
Critical	9.8	CVE-2022-37598
Critical	9.8	CVE-2023-42282
Critical	9.8	CVE-2023-45311
Critical	9.8	CVE-2023-45311
Critical	9.3	CVE-2022-1650
High	8.8	CVE-2018-3728
High	8.6	CVE-2021-37701
High	8.6	CVE-2021-37712
High	8.6	CVE-2021-37713
High	8.1	CVE-2021-32803
High	8.1	CVE-2021-32804
High	7.7	CVE-2020-13822
High	7.5	CVE-2018-16469
High	7.5	CVE-2018-20834
High	7.5	CVE-2018-3737
High	7.5	CVE-2021-23424
High	7.5	CVE-2021-28092
High	7.5	CVE-2021-29059
High	7.5	CVE-2021-33623
High	7.5	CVE-2021-3777
High	7.5	CVE-2022-29167
High	7.5	CVE-2022-29167
High	7.5	WS-2019-0541
High	7.5	WS-2020-0091
High	7.5	WS-2020-0450
High	7.5	WS-2021-0152
High	7.4	WS-2018-0588
High	7.4	WS-2018-0588
High	7.3	CVE-2020-8116
Medium	6.8	CVE-2020-28498
Medium	6.5	CVE-2018-21270
Medium	6.5	CVE-2021-23386
Medium	5.9	WS-2019-0424
Medium	5.9	WS-2019-0427
Medium	5.6	CVE-2020-7598
Medium	5.6	CVE-2020-7598
Medium	5.5	CVE-2019-13173
Medium	5.3	CVE-2017-16028
Medium	5.3	CVE-2021-23362
Medium	5.3	CVE-2021-29060
Medium	5.3	CVE-2022-33987
Medium	5.1	WS-2019-0307
Medium	4.8	WS-2018-0103

By merging this PR, the issue #94 will be automatically resolved and closed:

Severity	CVSS Score	CVE
Critical	9.8	CVE-2018-3774
Critical	9.8	CVE-2018-6342
Critical	9.8	CVE-2022-0691
Critical	9.1	CVE-2022-0686
High	8.1	WS-2019-0063
High	7.8	CVE-2021-43138
High	7.5	CVE-2017-16099
High	7.5	CVE-2017-16118
High	7.5	CVE-2017-16138
High	7.5	CVE-2018-14732
High	7.5	CVE-2020-7662
High	7.5	CVE-2021-23382
High	7.5	CVE-2021-23382
High	7.5	CVE-2021-27516
High	7.5	WS-2019-0032
High	7.1	WS-2018-0590
Medium	6.5	CVE-2020-26291
Medium	6.1	CVE-2021-3647
Medium	6.1	CVE-2022-0868
Medium	6.1	CVE-2022-1233
Medium	6.1	CVE-2022-1243
Medium	5.6	CVE-2020-15366
Medium	5.6	CVE-2021-24033
Medium	5.3	CVE-2020-8124
Medium	5.3	CVE-2021-27515
Medium	5.3	CVE-2021-3664
Medium	5.3	CVE-2022-0512
Medium	5.3	CVE-2022-0639
Medium	5.3	CVE-2022-24723
Medium	5.3	WS-2018-0347
Medium	5.3	WS-2019-0017
Low	3.7	WS-2018-0589

By merging this PR, the issue #59 will be automatically resolved and closed:

Severity	CVSS Score	CVE
Medium	6.5	CVE-2022-0155
Medium	6.1	CVE-2023-26159
Medium	5.9	CVE-2022-0536

---

Release Notes

facebook/create-react-app (react-scripts)

v2.0.3

Compare Source

2.0.3 (October 1, 2018)

Create React App 2.0 brings a year’s worth of improvements in a single dependency update.
We summarized all of the changes in a blog post!

Check it out: Create React App 2.0: Babel 7, Sass, and More.

It provides a high-level overview of new features and improvements. Now let's see how to update your app to the latest version in detail.

Migrating from 1.x to 2.0.3

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

npm install --save --save-exact react-scripts@2.0.3

or

yarn add --exact react-scripts@2.0.3

If you previously ejected but now want to upgrade, one common solution is to find the commits where you ejected (and any subsequent commits changing the configuration), revert them, upgrade, and later optionally eject again. It’s also possible that the feature you ejected for (maybe Sass or CSS Modules?) is now supported out of the box. You can find a list of notable new features in the Create React App 2.0 blog post.

Breaking Changes

Like any major release, react-scripts@2.0 contains a few breaking changes. We expect that they won't affect every user, but we recommend to scan over these sections to see if something is relevant to you. If we missed something, please file a new issue.

Node 6 is no longer supported

Please upgrade to Node 8 (LTS) or later.

Polyfills for IE 9, IE 10, and IE 11 are no longer included 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

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.

Dynamic import() of a CommonJS module now has a .default property

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);

require.ensure() is superseded by dynamic import()

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

Object proxy configuration is superseded by src/setupProxy.js

To check if action is required, look for the proxy key in package.json and follow this table:

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.

It's worth highlighting: if your proxy field is a string, e.g. http://localhost:5000, or you don't have it, skip this section. This feature is still supported and has the same behavior.

If your proxy is an object, that means you are using the advanced proxy configuration. It has become fully customizable so we removed the limited support for the object-style configuration. Here's how to recreate it.

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

npm install http-proxy-middleware

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.

.mjs file extension support is 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.

PropTypes definitions are now removed in production

Normally, this shouldn't affect your logic and should make the resulting bundle smaller. However, you may be relying on PropTypes definition for production logic. This is not recommended, and will break now. If a library does it, one possible solution is to file an issue in it with a proposal to use a different field (not propTypes) to signal that the declaration needs to be retained.

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

For a readable summary of the changes, check out our blog post.

For the detailed changelog, please see CHANGELOG.md.

v2.0.2

Compare Source

v2.0.1

Compare Source

v2.0.0

Compare Source

---

• If you want to rebase/retry this PR, check this box