Hanging at 'Files successfully emitted, waiting for typecheck results...'

[sandorvasas]

3.4.1
This just started happening and can't get rid of it. Without any package changes. It had been working alright, then suddenly hangs forever. Tried npm reinstall --no-cache, updated packages to 3.4.1. Have no idea what's causing it.

Downgrading typescript (used to be 3.7.5) to 3.3 or upgrading it to 3.8.3 didn't help either. Building in node 13.7 & node 13.10, with same results.

tsconfig is the same as in the ejected CRA with additional

"experimentalDecorators": true,
    "noImplicitAny": false,
    "strictNullChecks": false

[sandorvasas]

Resolved. I don't know what the initial problem was, since, again, I hadn't changed any packages, but I created a new CRA project with typescript and copied the libs from package.json. Works fine for now.

[sandorvasas]

No, sorry. It's back again. Worked for two times, and now hanging again.

[ulrichb]

Same here.

.. and I get ReferenceError: _createSuper is not defined right at the start-up when accessing localhost:3000.

[ulrichb]

Also tried to delete the babel cache.

... after reverting to 3.4.0 everything works again.

[sandorvasas]

Removed package-lock.json, and did an npm install --package-lock. Tried 3 times, it's working (still). Previoulsy meanwhile I had run an npm audit fix, so I believe (and hope) that breaks the compilation for CRA 3.4.1. So don't run npm audit fix people!

[ulrichb]

Hmmm, after deleting node_modules + package-lock.json, I get the following error now:

Module parse failed: Cannot use keyword 'await' outside an async function (85:31)
File was processed with these loaders:
 * ./node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.

(Cannot use keyword 'await' outside an async function is not correct, it's indeed an async method.)

[Wholteza]

I'm currently experiencing the same issue with the dev server getting stuck on Files successfully emitted, waiting for typecheck results....

I tried the steps @sandorvasas noted above and it is still not fixing the issue for me.
@sandorvasas are you using any web workers with workerize perhaps?

[samheutmaker]

I'm seeing this same issue just pop up with the dev server. Deleted node_modules and re-installed, same result. If I let the process hang for long enough it fails with JavaScript heap out of memory.

[ulrichb]

I just ran another test: npm un react-scripts && npm i react-scripts@3.4.0 (re-install).

Now the start is not hanging, but I still have the ReferenceError: _createSuper is not defined error.

... so this error definitely has to do with updated indirect dependencies (probably Babel which has been updated from 7.8.x to 7.9.0).

[ulrichb]

=> babel/babel#11336

[sandorvasas]

@samheutmaker Try increasing max_old_space_size.
node --max_old_space_size=8192 scripts/start.js

[C-Higgins]

Can confirm this is happening as well on a fresh ejected project. It hangs on that message, but after you change a file to trigger a recompile, it stops hanging until you restart the dev server.

[Wholteza]

I've now tried with a fresh and empty CRA and i can confirm that for me it does not happen, exact package versions are listed below if you're interested.

However i was using workerize-loader to use a web worker to convert images to base-64 strings in the
background.

The import statement needed to use the worker was using a custom format:

import createWorker, {
  Workerized
} from "workerize-loader!./my-worker-file.worker";

And this worked because i had a custom typings file:

declare module "workerize-loader!*" {
  type AnyFunction = (...args: any[]) => any;
  type Async<F extends AnyFunction> = (
    ...args: Parameters<F>
  ) => Promise<ReturnType<F>>;

  export type Workerized<T> = Worker &
    { [K in keyof T]: T[K] extends AnyFunction ? Async<T[K]> : never };

  function createInstance<T>(): Workerized<T>;
  export = createInstance;
}

The import statement above also needed a // eslint-disable-next-line, when i removed it i saw that the error was stating that you shouldn't use custom imports to modify the webpack build.
This was build by my friend so i did not know what the effects were.

As soon as i added these files and used them in the new fresh CRA project i got locked at the message mentioned in the issue title.

It's not likely that you're facing this exact issue, but maybe you have custom typing somewhere that is causing this. I thought I'd put it here for future readers.

This will probably lead to us ejecting from CRA instead, since we have a couple of things that needs it.

Here's our exact package versions, since i did not get the error without the workerize-loader package, maybe you'd like to try the version of react-scripts we're using. Beware that we are using slightly older versions of the packages since we're hunting problems of our own with this project:

{
  "name": "my-app",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@babel/plugin-proposal-optional-chaining": "7.7.5",
    "@mdi/js": "4.8.95",
    "@mdi/react": "1.2.1",
    "@types/jest": "24.0.17",
    "@types/node": "12.7.1",
    "@types/react": "16.9.1",
    "@types/react-dom": "16.8.5",
    "file-saver": "2.0.2",
    "moment": "2.24.0",
    "react": "16.12.0",
    "react-dom": "16.12.0",
    "react-scripts": "3.4.0",
    "typescript": "3.7.3",
    "workerize-loader": "1.1.0"
  },
  "devDependencies": {
    "@types/file-saver": "2.0.1",
    "eslint": "6.8.0"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "react-app"
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
  "babel": {
    "plugins": [
      "@babel/plugin-proposal-optional-chaining"
    ]
  }
}

[mrdaiking]

Does anybody get this error like me? I have tried to up and downgrade the version of babel. But it still occurs? Could you help me explain exactly what is it? Thanks!

[ulrichb]

@KyNguyenDai => babel/babel#11336

[sandorvasas]

Update as of today: Appeared again. Seems totally random when it appears or goes away

[pixelkritzel]

Same here.

But if I run yarn tsc --noEmit it's done in a second

[pixelkritzel]

Even better:

I did a yarn eject and changed in webpack.config.js this line to useTypescriptIncrementalApi: false, and it works again.

Will roll back and edit inside the node_modules folder for now.

[elis]

I've now tried with a fresh and empty CRA and i can confirm that for me it does not happen, exact package versions are listed below if you're interested.

However i was using workerize-loader to use a web worker to convert images to base-64 strings in the
background.

The import statement needed to use the worker was using a custom format:

import createWorker, {
  Workerized
} from "workerize-loader!./my-worker-file.worker";

And this worked because i had a custom typings file:

declare module "workerize-loader!*" {
  type AnyFunction = (...args: any[]) => any;
  type Async<F extends AnyFunction> = (
    ...args: Parameters<F>
  ) => Promise<ReturnType<F>>;

  export type Workerized<T> = Worker &
    { [K in keyof T]: T[K] extends AnyFunction ? Async<T[K]> : never };

  function createInstance<T>(): Workerized<T>;
  export = createInstance;
}

The import statement above also needed a // eslint-disable-next-line, when i removed it i saw that the error was stating that you shouldn't use custom imports to modify the webpack build.
This was build by my friend so i did not know what the effects were.

As soon as i added these files and used them in the new fresh CRA project i got locked at the message mentioned in the issue title.

It's not likely that you're facing this exact issue, but maybe you have custom typing somewhere that is causing this. I thought I'd put it here for future readers.

This will probably lead to us ejecting from CRA instead, since we have a couple of things that needs it.

Here's our exact package versions, since i did not get the error without the workerize-loader package, maybe you'd like to try the version of react-scripts we're using. Beware that we are using slightly older versions of the packages since we're hunting problems of our own with this project:

{
  "name": "my-app",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@babel/plugin-proposal-optional-chaining": "7.7.5",
    "@mdi/js": "4.8.95",
    "@mdi/react": "1.2.1",
    "@types/jest": "24.0.17",
    "@types/node": "12.7.1",
    "@types/react": "16.9.1",
    "@types/react-dom": "16.8.5",
    "file-saver": "2.0.2",
    "moment": "2.24.0",
    "react": "16.12.0",
    "react-dom": "16.12.0",
    "react-scripts": "3.4.0",
    "typescript": "3.7.3",
    "workerize-loader": "1.1.0"
  },
  "devDependencies": {
    "@types/file-saver": "2.0.1",
    "eslint": "6.8.0"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "react-app"
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
  "babel": {
    "plugins": [
      "@babel/plugin-proposal-optional-chaining"
    ]
  }
}

I have a very similar issue I'm experiencing for the last couple of weeks - I was sure it's related to me importing babel/rollup in some areas of the code.

My setup is very similar with workerize loader and typescript - only that I have partial typescript throughout the app and the part loading the loader is plain jsx - so I never noticed it's related.

On top of that I'm loading the worker file twice, once as a worker and once as a regular module.

Removing the workerize loader import resolved my issue! Now simply to rewrite the API between worker and main thread.

[sixhellstations]

Revert to 3.4.0 solve this issue for me

[h-morales]

im trying to run a fresh install of ionic react. when running ionic serve its hanging at "Files successfully emitted, waiting for typecheck results...". everything fresh install from nodejs to ionic..

[dugokontov]

I had same issue. Problem in my repository was that we used to use jsDocs for type annotation in js files, and I had wrong type declaration in code, like this:

/** @type {import('./../filePath').} */
let variable;

Notice that there is nothing after .. After removing this line everything worked as expected.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stale]

This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue.

[rickihastings]

I'm getting the same issue, tried everything in here, nothing fixes it apart from reverting which isn't ideal.

[bugwheels94]

Typescript Language Server is a memory eater (2GB) and (3GB) in vscode/vim extension. Some Times this error comes up when Out of Memory Happens. Create Swap or increase memory to mitigate it. I run it in WSL so creating swap(to save RAM) worked for me.

[bluenote10]

FYI I have analyzed this issue a little bit and opened #10871 to include a reproduction attempt. I'm pretty sure that it involves a race condition, so it is unlikely to reproduce the problem with 100%.

[aghArdeshir]

I face this too. In my case there is a lerna project with 12 packages in it. I updated one of the branches after a while (~800 file changes) and started one of the packages, it is taking forever in Files successfully emitted, waiting for typecheck results...

I expected there to be a process regarding node/typescript that is eating CPU or RAM, but there is nothing special. The simple node, npm & yarn related processes are not using CPU.

[pixelkritzel]

Self quote from here:

As far as I understood it, it's due to Typescripts incremental API, which is invoked by fork-ts-checker-webpack-plugin. They have an update, but it isn't part of CRA yet.

TypeStrong/fork-ts-checker-webpack-plugin#463

My personal solution is to opt out of the incremental API by patching CRA Webpack config.

https://github.com/pixelkritzel/savages/blob/master/patchWebpackConfig.js

[jdkern11]

This issue began for me in one of my projects after installing typescript-plugin-css-modules. I removed this and this issue has ceased since. I do not know if this information is helpful, but I thought I would add it.

[GaneshMBabu21]

Try this guys...
npm uninstall react-scripts -S
npm i react-scripts@3.4.0
ionic serve

[Daimon31999]

Hey guys, I solved this issue with yarn.lock (or package-lock)

1. just use previous (working) version of lock file
2. clean project with this script:

rm -rf node_modules
rm -f package-lock.json
rm -f yarn.lock
npm cache clean --force

3. yarn install
4. done !