create-react-app: 4.0 alpha - TypeError: Cannot add property noFallthroughCasesInSwitch, object is not extensible

I was able to sidestep this error by adding "noFallthroughCasesInSwitch": true to compilerOptions in my tsconfig.json (which I think just avoids the need for this code to run at all).

I have another version of this. After adding noFallthroughCasesInSwitch like suggested above I get this error:

TypeError: Cannot add property jsx, object is not extensible
    at verifyTypeScriptSetup (...../node_modules/react-scripts/scripts/utils/verifyTypeScriptSetup.js:239:43)
    at Object.<anonymous> (...../node_modules/react-scripts/scripts/test.js:32:1)
    at Module._compile (internal/modules/cjs/loader.js:1158:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1178:10)
    at Module.load (internal/modules/cjs/loader.js:1002:32)
    at Function.Module._load (internal/modules/cjs/loader.js:901:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:74:12)
    at internal/main/run_main_module.js:18:47

I also got that too. Just figured out that I have to change "compilerOptions.jsx" from "preserve" to "react".

"compilerOptions": {
  "jsx": "react",
  "noFallthroughCasesInSwitch": true
}

Didn’t read too much in to this but this seems to be working for me. Not sure why Immer is being used in this case where the readTsConfig object doesn’t seem to be changed at all? Guessing there’s some need for a shallow or deep copy of readTsConfig?

verifyTypeScriptSetup.js

Before:

let result;
parsedTsConfig = immer(readTsConfig, config => {
  result = ts.parseJsonConfigFileContent(
    config,
     ts.sys,
     path.dirname(paths.appTsConfig)
  );
});

After:

parsedTsConfig = {...readTsConfig};

const result = ts.parseJsonConfigFileContent(
  parsedTsConfig,
  ts.sys,
  path.dirname(paths.appTsConfig)
);
  

Now this problem is released. Why this one is ignored and lib is released with the critical bugs?

@ianschmitz What about paths? I know this issue was specifically about noFallthroughCasesInSwitch, but many people complained about paths here as well and it’s from the same family of issues.

I am getting a similar error, but for a different property…

Cannot add property paths, object is not extensible

I know that paths are technically not supported by CRA, but I’ve been using that with the current stable version just fine. Please, don’t make it harder than it is already. There is no practical reason why paths should be banned from use.

@flppv It still doesn’t solve the “paths”, because that’s an object and no just primitive value. I am surprised they published 4.0.0 without handling such a “major” flaw.

CRA 4.0.0 has been released today and I encountered this same bug in the released version when trying to upgrade to it.

{project}/node_modules/react-scripts/scripts/utils/verifyTypeScriptSetup.js:231
        appTsConfig.compilerOptions[option] = suggested;
                                            ^

TypeError: Cannot add property noFallthroughCasesInSwitch, object is not extensible
    at verifyTypeScriptSetup ({project}/node_modules/react-scripts/scripts/utils/verifyTypeScriptSetup.js:231:45)
    at Object.<anonymous> ({project}/node_modules/react-scripts/scripts/start.js:31:1)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12)
    at internal/main/run_main_module.js:17:47

It seems like this issue should have been expected and easy to fix. i.e. The config value from readConfigFile should be considered immutable and CRA should not be modifying it.

Same issue here and fixed with the "noFallthroughCasesInSwitch": true solution above.

Don’t really get why this was closed when this is still breaking when upgrading from an existing project to CRA 4. The above change from https://github.com/facebook/create-react-app/issues/9429#issuecomment-669615656 @jamsch works - so can we please release this soon as a quick patch?

I have another version of this. After adding noFallthroughCasesInSwitch like suggested above I get this error:

TypeError: Cannot add property jsx, object is not extensible
    at verifyTypeScriptSetup (...../node_modules/react-scripts/scripts/utils/verifyTypeScriptSetup.js:239:43)
    at Object.<anonymous> (...../node_modules/react-scripts/scripts/test.js:32:1)
    at Module._compile (internal/modules/cjs/loader.js:1158:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1178:10)
    at Module.load (internal/modules/cjs/loader.js:1002:32)
    at Function.Module._load (internal/modules/cjs/loader.js:901:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:74:12)
    at internal/main/run_main_module.js:18:47

@ianschmitz I honestly haven’t tried, but seeing 30+ people giving 👍 and seeing this still present in the code, I don’t think it’s handled 😃

https://github.com/facebook/create-react-app/blob/aec42e2cc05fe0799a3b73830b874757e9e3f561/packages/react-scripts/scripts/utils/verifyTypeScriptSetup.js#L159

Fixed in #9921.

@jamsch I can confirm that the above change fixed it for me. 🙂

Side note on this: we just ran into this issue upgrading our React app to react-scripts v4. Running yarn start resulted in this error, but running yarn build did add "noFallthroughCasesInSwitch": true to our tsconfig.json file. After that, running yarn start worked.

Note: this also happens if you have configured paths in your tsconfig. I have a set up with “react-app-rewired” in a monorepo with some webpack overrides to accommodate for paths. This bug prevents me from using v4 at all.

@FredyC this is not true, CRA 3 wasn’t forbidding the definition of the paths property in tsconfig, and that was nice for monorepo, for alias support. Heck, even till 4.0.0-next.64 it was totally fine to use it! Now CRA 4 basically breaks typescript monorepo due to this new enforcement, without providing any reason as of why this is not allowed anymore.

hey guys! (@Annihil, @jamsch, @rizkyramadhan, …whoever needs it)

Tried this workaround for monorepo (with Lerna) - and it worked for me. relevant for those who have “paths” entry on his tsconfig.json file.

using patch-package, I commented out row 159 on react-scripts/scripts/utils/verifyTypeScriptSetup.js, So patch file will be looked like that:

diff --git a/node_modules/react-scripts/scripts/utils/verifyTypeScriptSetup.js b/node_modules/react-scripts/scripts/utils/verifyTypeScriptSetup.js
index 00139ee..4b8bfe3 100644
--- a/node_modules/react-scripts/scripts/utils/verifyTypeScriptSetup.js
+++ b/node_modules/react-scripts/scripts/utils/verifyTypeScriptSetup.js
@@ -156,7 +156,7 @@ function verifyTypeScriptSetup() {
           : 'react',
       reason: 'to support the new JSX transform in React 17',
     },
-    paths: { value: undefined, reason: 'aliased imports are not supported' },
+    // paths: { value: undefined, reason: 'aliased imports are not supported' },
   };
 
   const formatDiagnosticHost = {

this allows me to maintain the path entry, and so far didn’t found it break anything. will update otherwise. vscode still type suggestions still works 😃

P.S, using react-app-rewired as well, and adding aliases…

After upgrading with yarn upgrade-interactive --latest I’m getting the mentioned noFallthroughCasesInSwitch error when I try to yarn start. Deleting and redownloading node_moduels didn’t help either.

Edit: So I’ve created a fresh 4.0.0 CRA and it seems that my dependencies are same except there is now a "web-vitals": "^0.2.4" dependency, not sure why that’s there.

Most importanlty tsconfig.json now has the "noFallthroughCasesInSwitch": true, set by defualt, so it’s not a workaround to set it but the default behaviour. I feel like that this should definitely be mentioned in the upgrade guide.

@michchan

I also got that too. Just figured out that I have to change "compilerOptions.jsx" from "preserve" to "react".

Adding "jsx: "react" does not fix the issue. In fact, if you add jsx: "preserve", the script may still run fine. It only throws if you don’t specify some of the options in tsconfig.json that have suggested values. When you do that the code assigning the suggested value is executed and crashes the script.

For example the script will crash if you omit the allowJs option which can be suggested, the same can be applied to many other options but most of them except noFallthroughCasesInSwitch are already specified in the default tsconfig.json .

I’ve tried adding

I have another version of this. After adding noFallthroughCasesInSwitch like suggested above I get this error:

TypeError: Cannot add property jsx, object is not extensible
    at verifyTypeScriptSetup (...../node_modules/react-scripts/scripts/utils/verifyTypeScriptSetup.js:239:43)
    at Object.<anonymous> (...../node_modules/react-scripts/scripts/test.js:32:1)
    at Module._compile (internal/modules/cjs/loader.js:1158:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1178:10)
    at Module.load (internal/modules/cjs/loader.js:1002:32)
    at Function.Module._load (internal/modules/cjs/loader.js:901:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:74:12)
    at internal/main/run_main_module.js:18:47

I also got that too. Just figured out that I have to change "compilerOptions.jsx" from "preserve" to "react".

"compilerOptions": {
  "jsx": "react",
  "noFallthroughCasesInSwitch": true
}

Thanks for this, confirming it worked for me too! On its own, "noFallthroughCasesInSwitch": true didn’t fix the issue. But adding "jsx: "react" has completely resolved it for me.

#9921 is included with react-scripts v4.0.1. This also fixes the paths property.

Upgraded from react-scripts 3.4.3 to 4.0.0, got the same issue (as the topic starter).

This helped https://github.com/facebook/create-react-app/issues/9429#issuecomment-669615656 Applied the change as a patch to react-scripts module.

Deleting tsconfig.json doesn’t help, since the generated file does not match my preference and if I update it, the build fails again.

Looks like the fix has been merged but not released yet https://github.com/facebook/create-react-app/pull/9921

Yeah for evreyone else I can confirm that it works only when both changes listed above are applied

How do you suggest to edit tsconfig.json when there is no tsconfig.json because I’m trying to just create new project by npx create-react-app my-app?

You can create a new tsconfig.json file by running tsc --init.

npx tsc --init

Without paths property in tsconfig, ts-jest also breaks in a monorepo. Falling back to 4.0.0-next.64

I’m also seeing the above (noFallthroughCasesInSwitch object is not extensible) error, even after running npm ci As mentioned above, adding this to tsconfig.json “noFallthroughCasesInSwitch”: true seems to have fixed that error

also getting this error

Also faced error Cannot add property noFallthroughCasesInSwitch, object is not extensible, and added "noFallthroughCasesInSwitch": true to my tsconfig.json. But after that I got this: Cannot read property 'use' of undefined. Has anyone faced this issue too? There are my logs:

0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   'C:\\Program Files\\nodejs\\node.exe',
1 verbose cli   'C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli   'start'
1 verbose cli ]
2 info using npm@6.14.6
3 info using node@v12.18.4
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle intranet@0.1.0~prestart: intranet@0.1.0
6 info lifecycle intranet@0.1.0~start: intranet@0.1.0
7 verbose lifecycle intranet@0.1.0~start: unsafe-perm in lifecycle true
8 verbose lifecycle intranet@0.1.0~start: PATH: C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin;D:\Binary\bs-intranet\frontend\node_modules\.bin;D:\oracle\bin;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Python34\;C:\Python34\Scripts;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\150\Tools\Binn\;C:\Program Files\Microsoft SQL Server\150\Tools\Binn\;C:\Program Files\Microsoft SQL Server\150\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn\;C:\Program Files\nodejs\;C:\Program Files\Docker\Docker\resources\bin;C:\ProgramData\DockerDesktop\version-bin;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Python37\Scripts;C:\ProgramData\chocolatey\bin;C:\Gradle\gradle-6.0.1\bin;C:\Windows\System32;C:\Users\Anton\AppData\Local\Microsoft\WindowsApps;C:\Users\Anton\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\Anton\.dotnet\tools;C:\Users\Anton\AppData\Roaming\npm;C:\Users\Anton\.dotnet\tools;C:\Python37\Scripts;C:\Program Files (x86)\Rico Suter\NSwagStudio\;C:\Gradle\gradle-6.0.1\bin;C:\Program Files\JetBrains\IntelliJ IDEA 2020.2.3\bin;;C:\Windows\System32;
9 verbose lifecycle intranet@0.1.0~start: CWD: D:\Binary\bs-intranet\frontend
10 silly lifecycle intranet@0.1.0~start: Args: [ '/d /s /c', 'react-app-rewired start' ]
11 silly lifecycle intranet@0.1.0~start: Returned: code: 1  signal: null
12 info lifecycle intranet@0.1.0~start: Failed to exec start script
13 verbose stack Error: intranet@0.1.0 start: `react-app-rewired start`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\index.js:332:16)
13 verbose stack     at EventEmitter.emit (events.js:315:20)
13 verbose stack     at ChildProcess.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:315:20)
13 verbose stack     at maybeClose (internal/child_process.js:1021:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5)
14 verbose pkgid intranet@0.1.0
15 verbose cwd D:\Binary\bs-intranet\frontend
16 verbose Windows_NT 10.0.19041
17 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "start"
18 verbose node v12.18.4
19 verbose npm  v6.14.6
20 error code ELIFECYCLE
21 error errno 1
22 error intranet@0.1.0 start: `react-app-rewired start`
22 error Exit status 1
23 error Failed at the intranet@0.1.0 start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

P.S. I’d also tried to set up noFallthroughCasesInSwitch to false, but this didn’t help 😕

@FredyC does the fix not work for paths?

I was able to sidestep this error by adding "noFallthroughCasesInSwitch": true to compilerOptions in my tsconfig.json (which I think just avoids the need for this code to run at all).

Adding this to tsconfig.json fixed it for me too

@michchan I can confirm on my local machine that the crash doesn’t depend on which values you provide to the compiler options, it depends on whether or not the options are specified in your tsconfig.json. You should not use the fix from https://github.com/facebook/create-react-app/issues/9429#issuecomment-669615656 because it’s invasive, hard to maintain, and it may lead to other bugs since it changes the behavior of the script.

The proposed solution in my https://github.com/facebook/create-react-app/issues/9429#issuecomment-715903925 is not evasive and easier to implement, without meddling with anything inside the node_modules

Maybe there should be a SKIP_TS_SETUP_CHECK flag, similar to SKIP_PREFLIGHT_CHECK

https://github.com/facebook/create-react-app/blob/d5c0fe287a6bc24c60ee52ca768bdf3a10b937e1/packages/react-scripts/scripts/start.js#L22-L32

Note: this also happens if you have configured paths in your tsconfig. I have a set up with “react-app-rewired” in a monorepo with some webpack overrides to accommodate for paths. This bug prevents me from using v4 at all.

This fixed the issue, but vscode cannot recognise the paths, it is a deal breaker for me