React: scheduler callback is not a function

[Fyzu]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
After update react env from 16.8.6 -> 16.9.0
I catch errors:

scheduler.development.js:107 Uncaught TypeError: callback is not a function
    at flushFirstCallback (scheduler.development.js:107)
    at flushWork (scheduler.development.js:219)
    at MessagePort../node_modules/scheduler/cjs/scheduler.development.js.channel.port1.onmessage (scheduler.development.js:611)
flushFirstCallback @ scheduler.development.js:107
flushWork @ scheduler.development.js:219
./node_modules/scheduler/cjs/scheduler.development.js.channel.port1.onmessage @ scheduler.development.js:611

What is the expected behavior?
No errors

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
Version 16.9.0
On 16.8.6 all works fine

[gaearon]

You probably forgot to update some of the packages. Ensure that you have 16.9.0 of both React and ReactDOM, for example. If this doesn't help, try deleting node_modules and installing again.

[Fyzu]

@hot-loader/react-dom affect on it, thx for answer

[knitesh]

deleted node_modules, updated react and react-dom to 16.9.0, still having this issue. I am running it inside the gatsby project.

[semi-sentient]

I have the exact same issue after upgrading from 16.8.6 to 16.9.0 (both react and react-dom). Tried deleting node_modules and reinstalling, but error persists and prevents the app from loading.

Uncaught TypeError: callback is not a function
    at flushFirstCallback (scheduler.development.js?bacd:107)
    at flushWork (scheduler.development.js?bacd:219)
    at MessagePort.channel.port1.onmessage (scheduler.development.js?bacd:611)

Edit: The solution posted by @RyanWarner is the only one that worked for me.

[eps1lon]

For anybody having issues after deleting node_modules: Try verifying you only have a single scheduler entry in the lockfile of your package manager. For yarn use yarn why scheduler and for npm npm list scheduler. It should only list a single one. For yarn you can just remove all scheduler entries and run yarn again. This should result in a single entry. No idea about npm other than manually merging the entries.

[RyanWarner]

Deleting both node_modules and package-lock.json (and then npm i) fixed it for me.

[iiilya]

I have gatsby and react-dom installing two different versions of scheduler. npm install --save scheduler was the solution for my case.

[gaearon]

Installing it explicitly at the top level is a bad idea and will only create more problems in the future, as the version you installed will get out of sync with the version used by React. Please don’t do that.

[crgeee]

hit the same issue, only remedy was installing scheduler. tried removing node_modules, yarn.lock and reinstalling via yarn. also double checked all versions to ensure 16.9. This happened when upgrading from 16.8.6

running yarn why scheduler revealed there are older versions < 0.14

[Aghassi]

@gaearon Instead of installing it at the top level, I've asked some devs to use https://yarnpkg.com/en/docs/package-json#toc-resolutions so as to resolve the latest version. However, it seems without forcibly hoisting the scheduler, yarn/npm may resolve the "most compatible" version, which in this case is _not_ the version that React needs.

However, when testing some more, our environments don't experience this issue because our environment use the UMD bundle, so it's isolated and repeatable. Users experiencing this issue only seem to see it when they are running locally with webpack dev server serving up assets and bundling.

[gaearon]

running yarn why scheduler revealed there are older versions < 0.14

So where are they coming from?

[crgeee]

@gaearon the older versions of scheduler were from a few internal dependencies which have older versions of react / react-dom listed as dependencies (in this case 16.8.6 as they haven't upgraded). As @Aghassi stated the issue appeared only at build time where for some reason, it kept resolving down to 0.13.6

[Aghassi]

@gaearon Other internal dependencies specifying React as a dependency also indirectly need to resolve scheduler. I did a yarn why scheduler on one of those packages which was using React 16.8.6, and it returned the following:

➜ yarn why scheduler
yarn why v1.17.3
[1/4] 🤔  Why do we have the module "scheduler"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "[email protected]"
info Has been hoisted to "scheduler"
info Reasons this module exists
   - Hoisted from "react#scheduler"
   - Hoisted from "react-dom#scheduler"
info Disk size without dependencies: "128KB"
info Disk size with unique dependencies: "176KB"
info Disk size with transitive dependencies: "204KB"
info Number of shared dependencies: 3
=> Found "react-test-renderer#[email protected]"
info This module exists because "react-test-renderer" depends on it.
info Disk size without dependencies: "212KB"
info Disk size with unique dependencies: "260KB"
info Disk size with transitive dependencies: "288KB"
info Number of shared dependencies: 3
✨  Done in 0.64s.

Digging into the package.json of 16.8.6 I can see scheduler is stated as a dependency

  "dependencies": {
    "loose-envify": "^1.1.0",
    "object-assign": "^4.1.1",
    "prop-types": "^15.6.2",
    "scheduler": "^0.13.6"
  },

But, when I upgraded that package to have the latest React (16.9), and looked at the package.json I see the following in the dependencies block

  "dependencies": {
    "loose-envify": "^1.1.0",
    "object-assign": "^4.1.1",
    "prop-types": "^15.6.2"
  },

I also checked React-DOM:

16.8.6

  "dependencies": {
    "loose-envify": "^1.1.0",
    "object-assign": "^4.1.1",
    "prop-types": "^15.6.2",
    "scheduler": "^0.13.6"
  },

16.9

  "dependencies": {
    "loose-envify": "^1.1.0",
    "object-assign": "^4.1.1",
    "prop-types": "^15.6.2",
    "scheduler": "^0.15.0"
  },

Checking how ^ resolves on semver.npmjs.com, we can see that ^0.13.6 won't resolve to anything higher like 0.15.0

So what I'm _guessing_ is happening is that even if users specify 16.9 at the root of their project, it is still leaving the module resolution up to Yarn and NPM. Last I checked, Yarn and NPM take the "most common/compatible" version. So if you have enough dependencies that have React 16.8.6 as the sub package, the hoisted version of scheduler will be 0.13.6. A potential solution for this would be to either have scheduler be a full semver, or to have React pin dependencies so Yarn or NPM will nest a node_modules folder in the resolution structure with the exact version it cares about.

[Aghassi]

To add to the above, I think Webpack will pull in the hoisted module (top level resolution in node_modules). So if there are enough references to an older version of React in the module tree, they "win out" and cause 0.13.6 to be hoisted. That's the version that webpack would bundle and it would cause the issue that users are seeing since it is a version mismatch.

[gaearon]

the older versions of scheduler were from a few internal dependencies which have older versions of react / react-dom listed as dependencies (in this case 16.8.6 as they haven't upgraded).

This sounds like the root of your problem. Libraries using React (like components) shouldn’t specify it as a dependency. It should be a peer dependency.

The only exception to this rule is if a library some kind of wrapper around React itself which is very rare.

[Aghassi]

@gaearon thanks for the tip, we will try it out. There’s definitely some misunderstanding about how that works. Are there official docs that talk about packaging react at scale like this?

_{Sent with GitHawk}

[Aghassi]

Also, does that include things like component libraries?

_{Sent with GitHawk}

[teoboley]

If you use yarn, you can specify dependency resolutions in your package.json:

...
"resolutions": {
    "scheduler": "0.15.0"
  }
...

[Aghassi]

@teoboley Yup, we are aware of that. As per @gaearon, it seems that isn't recommended so we were trying to better understand the "right" wait to declare avoid specifying resolutions because that doesn't scale in a large enterprise.

[Yaolegol]

Walking around that issue I finded solution for my case (thanks all who leave a comment here) and only add:

1. if you have several versions of scheduler you can use with npm this
2. in any case after each manipulation with scheduler ALWAYS reload you react app (e.g. npm start)
   Thanks to everybody!