Exception during run: TypeError: behs.keys(...).filter is not a function

josdejong commented

2025-04-09 16:30:13 +00:00

Collaborator

When I run pnpm test on my Windows machine, I get the following error. Same happens when running Linux via WSL.

pnpm test

> nanomath@1.0.0 test C:\Users\wjosd\projects\nanomath
> mocha ./**/*.spec.js


 Exception during run: TypeError: behs.keys(...).filter is not a function
    at TypeDispatcher._clearBehaviorsMatching (file:///C:/Users/wjosd/projects/nanomath/src/core/TypeDispatcher.js:253:36)
    at TypeDispatcher.merge (file:///C:/Users/wjosd/projects/nanomath/src/core/TypeDispatcher.js:120:24)
    at TypeDispatcher.merge (file:///C:/Users/wjosd/projects/nanomath/src/core/TypeDispatcher.js:133:18)
    at new TypeDispatcher (file:///C:/Users/wjosd/projects/nanomath/src/core/TypeDispatcher.js:26:38)
    at file:///C:/Users/wjosd/projects/nanomath/src/nanomath.js:5:14
    at ModuleJob.run (node:internal/modules/esm/module_job:234:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:473:24)
    at async formattedImport (C:\Users\wjosd\projects\nanomath\node_modules\.pnpm\mocha@11.1.0\node_modules\mocha\lib\nodejs\esm-utils.js:9:14)
    at async exports.requireOrImport (C:\Users\wjosd\projects\nanomath\node_modules\.pnpm\mocha@11.1.0\node_modules\mocha\lib\nodejs\esm-utils.js:42:28)
    at async exports.loadFilesAsync (C:\Users\wjosd\projects\nanomath\node_modules\.pnpm\mocha@11.1.0\node_modules\mocha\lib\nodejs\esm-utils.js:100:20)
    at async singleRun (C:\Users\wjosd\projects\nanomath\node_modules\.pnpm\mocha@11.1.0\node_modules\mocha\lib\cli\run-helpers.js:162:3)
    at async exports.handler (C:\Users\wjosd\projects\nanomath\node_modules\.pnpm\mocha@11.1.0\node_modules\mocha\lib\cli\run.js:375:5)

Any idea?

When I run `pnpm test` on my Windows machine, I get the following error. Same happens when running Linux via WSL. ``` pnpm test > nanomath@1.0.0 test C:\Users\wjosd\projects\nanomath > mocha ./**/*.spec.js Exception during run: TypeError: behs.keys(...).filter is not a function at TypeDispatcher._clearBehaviorsMatching (file:///C:/Users/wjosd/projects/nanomath/src/core/TypeDispatcher.js:253:36) at TypeDispatcher.merge (file:///C:/Users/wjosd/projects/nanomath/src/core/TypeDispatcher.js:120:24) at TypeDispatcher.merge (file:///C:/Users/wjosd/projects/nanomath/src/core/TypeDispatcher.js:133:18) at new TypeDispatcher (file:///C:/Users/wjosd/projects/nanomath/src/core/TypeDispatcher.js:26:38) at file:///C:/Users/wjosd/projects/nanomath/src/nanomath.js:5:14 at ModuleJob.run (node:internal/modules/esm/module_job:234:25) at async ModuleLoader.import (node:internal/modules/esm/loader:473:24) at async formattedImport (C:\Users\wjosd\projects\nanomath\node_modules\.pnpm\mocha@11.1.0\node_modules\mocha\lib\nodejs\esm-utils.js:9:14) at async exports.requireOrImport (C:\Users\wjosd\projects\nanomath\node_modules\.pnpm\mocha@11.1.0\node_modules\mocha\lib\nodejs\esm-utils.js:42:28) at async exports.loadFilesAsync (C:\Users\wjosd\projects\nanomath\node_modules\.pnpm\mocha@11.1.0\node_modules\mocha\lib\nodejs\esm-utils.js:100:20) at async singleRun (C:\Users\wjosd\projects\nanomath\node_modules\.pnpm\mocha@11.1.0\node_modules\mocha\lib\cli\run-helpers.js:162:3) at async exports.handler (C:\Users\wjosd\projects\nanomath\node_modules\.pnpm\mocha@11.1.0\node_modules\mocha\lib\cli\run.js:375:5) ``` Any idea?

glen commented

2025-04-09 17:11:43 +00:00

Owner

Well, either there is an initialization order bug and the initialization order comes out different on Windows and Linux, or there's some Node version skew or something like that so that the Map.keys() interface is different on Windows? My point is that the only objects that are ever put as values in this._behaviors are Maps, so behs should either be undefined or a Map. If it was undefined, then it seems like the error would be that we can't look up keys on undefined. So it seems like behs must be a Map. But then keys() should return an iterator, unless there is some exception for empty maps or something like that. Hence the initialization-order worry. But the availability matrix shows that filter() on an iterator is only available in Node from version 22 on. So I think that the first order of business is for you to check the Node version that is running in the Windows environment you are using. If it is less than 22, try upgrading to 22 or higher, and see if that solves the issue. If it does, then the question becomes what's the best mechanism for expressing/enforcing that this project requires Node 22 or later? If it's not the Node version, I will try to spin this up in a Windows environment and see if I can reproduce.

Well, either there is an initialization order bug and the initialization order comes out different on Windows and Linux, or there's some Node version skew or something like that so that the Map.keys() interface is different on Windows? My point is that the only objects that are ever put as values in this._behaviors are Maps, so behs should either be undefined or a Map. If it was undefined, then it seems like the error would be that we can't look up `keys` on undefined. So it seems like behs must be a Map. But then keys() should return an iterator, unless there is some exception for empty maps or something like that. Hence the initialization-order worry. But the [availability matrix](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator/filter) shows that `filter()` on an iterator is only available in Node from version 22 on. So I think that the first order of business is for you to check the Node version that is running in the Windows environment you are using. If it is less than 22, try upgrading to 22 or higher, and see if that solves the issue. If it does, then the question becomes what's the best mechanism for expressing/enforcing that this project requires Node 22 or later? If it's not the Node version, I will try to spin this up in a Windows environment and see if I can reproduce.

josdejong commented

2025-04-10 17:52:52 +00:00

Author

Collaborator

Ok I managed to figure out what's going on. I'm running Nodejs 23 on Windows. But it turns out pnpm doesn't use the system installed version but it's own version of nodejs, which in my case was Node.js 20, you can check this with pnpm env --help. To let pnpm use a newer version, you can use pnpm env use --global 22, which runs fine in my case but after that pnpm still uses Node.js 20. What does work however is creating a .npmrc file in the root of the project with the following contents:

use-node-version=22.14.0

Shall I push a commit adding this file? Then everyone using the project will use the same version of Node.js, which is a good thing I think.

Ok I managed to figure out what's going on. I'm running Nodejs 23 on Windows. But it turns out pnpm doesn't use the system installed version but it's own version of nodejs, which in my case was Node.js 20, you can check this with `pnpm env --help`. To let pnpm use a newer version, you can use `pnpm env use --global 22`, which runs fine in my case but after that pnpm *still* uses Node.js 20. What does work however is creating a `.npmrc` file in the root of the project with the following contents: ``` use-node-version=22.14.0 ``` Shall I push a commit adding this file? Then everyone using the project will use the same version of Node.js, which is a good thing I think.

glen commented

2025-04-10 18:01:18 +00:00

Owner

Sure, fine by me. Note 'main' has branch protection so you will have to do a PR resolving this, but that shouldn't be a problem and feel free to merge it yourself if you like.