Rethink decision to make react-scripts a dependency instead of a devDependency

[mrwensveen]

Is your proposal related to a problem?

The decision to make react-scripts a dependency causes a lot of issues regarding perceived security vulnerabilities. Even though the issues themselves are technically harmless, these issues often break CI/CD flows and/or end up being reported here as actual issues.

Describe the solution you'd like

The decision to make react-scripts a dependency was in my opinion ill-conceived. There are issues with having react-scrips a devDependency as stated in the original pull request:

• The distinction does not make sense. Nonetheless, tools like npm audit are dependent on this distinction.
• Apparently some people build on the production server? They shouldn't.
• An actual run-time dependency in the form of a polyfill is included. This could be a separate (and optional?) dependency.
• Eject crashes in some situations (issue Ejecting crashes if no devDependencies exists in package.json #2655)
• Possibly other issues...

In my opinion, a shortcut was taken to work around some problems that should have been fixed separately.

Describe alternatives you've considered

It's possible to move react-scripts to devDependencies by hand, or to eject your React application. Both solve the problem (afaict) but a lot of people are not willing to do this or are unaware of the possibility.

Another possibility would be for the developers to update dependencies whenever a vulnerability pops up as fast as possible, and/or to help developers of dependent package to fix their dependencies. Maybe get Facebook to throw some money behind a React Vulnerability Strike Team (tm) or something.

Additional context

One way or another a solution is needed. Every time some vulnerability pops up I see a lot of frustration in the comments. Even though someone always politely explains the actual security implications, there are always a few people saying (and probably more people thinking) that you don't actually care that much about security. Rationally I know this not to be true, but I get frustrated as well sometimes (I'm only human after all).

[stahlmanDesign]

All of these issues are duplicates or are related:
#11136
#11131
#11118
#11116
#11109
#11092
#11081
#11077
#11067
#11054

and could be solved by #11102

[rvramesh]

I moved react-scripts to devDependencies from the default dependencies section and still got the same vulnerabilities in npm audit. Am I doing anything wrong?

npm version
{
'go-portal': '0.1.0',
npm: '6.14.13',
ares: '1.17.1',
brotli: '1.0.9',
cldr: '39.0',
icu: '69.1',
llhttp: '2.1.3',
modules: '83',
napi: '8',
nghttp2: '1.42.0',
node: '14.17.1',
openssl: '1.1.1k',
tz: '2021a',
unicode: '13.0',
uv: '1.41.0',
v8: '8.4.371.23-node.67',
zlib: '1.2.11'
}

[mrwensveen]

@rvramesh You're correct. The vulnerabilities will only be ignored when you run npm audit --production, which is usually the case when audit is integrated in your CI/CD setup. Without the option the output will show the vulnerability but with a [dev] tag.

[rvramesh]

@rvramesh You're correct. The vulnerabilities will only be ignored when you run npm audit --production, which is usually the case when audit is integrated in your CI/CD setup. Without the option the output will show the vulnerability but with a [dev] tag.

Thank you for the clarification. It helps

[illume]

Good proposal IMHO.

However I guess dev environments are also considered for security related issues. It's sometimes harder to use exploits on dev environments, but it still happens.

npm audit will still show problems, but maybe the issue-reporting-noise will only be reduced a little bit. I think most people just see the results printed after using npm - not from using npm audit --production in CI.

Seems faster security related updates would be a better fix, but moving react-scripts to devDependencies would still be an improvement.