Koa 2.x still broken in v1.1.2

[Robbilie]

Referencing https://github.com/inspect-js/is-generator-function/issues/45

I am currently trying to debug the issue, I am still getting the "is not a function" error and reverting to v1.1.0 resolves the issue. I am unsure what the issue with the import of the generator-function package is, its transpiled and minified in an ancient build pipeline so its really hard to debug.

I will post updates when i find out more…

[Robbilie]

var getGeneratorFunction = require('generator-function'); console.log(getGeneratorFunction);

yields

{ default: [Function (anonymous)] }

there seems to be a missmatch between different import/export systems…

[Robbilie]

the index.js require of the generator-function package uses the module and not the main field to load the package and the index.mjs loaded from a js context leads to this situation

a solution could be to check for the default field on the required package or make the function a named export

[ljharb]

What build process are you using? node never uses the module field.

[Robbilie]

its some very old webpack pipeline i believe

[Robbilie]

there might be a cleaner way to do this but adding this would make it work

[ljharb]

That .default thing shouldn't be there in this case though - iow it seems like it's an issue with your webpack config and the way it handles CJS/ESM interop.

[Robbilie]

When you load a module in js you always get the default field for modules with a default export. That's also what the other reporters in the other ticket showed in their code snippets.
If you use import() to load modules you also have to deal with the default field.

Given that our project has thousands of dependencies and your library being the only one causing issues I think chances are good that other libraries are handling it in a different way and therefore work.

[Robbilie]

think of it what you want and treat it with a grain of salt but according to some quick chat gpt "research" this behaviour is the webpack default (and i dont see any change to that in our webpack.config.js)

https://chatgpt.com/share/68e6af51-4e04-8008-9a63-ade2dbed4b67

i think there are 3 options:

• add a module implementation to is-generator-function
• adjust generator-function to behave the same for cjs and mjs imports
• i change the complete module resolution of my projects away from the webpack defaults just to make your library work again that broke during a patch release

your choice :D

[ljharb]

When you load a module in js you always get the default field for modules with a default export

That's what happens when you require an ES Module that hasn't set up a "module.exports" export, yes. This package only has a CJS module, so there should never be a .default property anywhere, and if there is, it's due to the tool you're using being broken.

Webpack < 5 is EOL, so certainly if you're using one of those versions, its defaults probably have not caught up with a quickly-evolving ecosystem.

Given those three options, I won't do the first, since there's no need; the second is already done (1 2), and the third is almost certainly inevitable if you're not using webpack 5.

[Robbilie]

you are right in that we are using an older version of webpack, apparently in combination with uglifyjs they both are not capable of fully and properly handling ESM imports which causes this issue. Id still like to point out that other libraries dont seem to run into this issue which i assume is because their setup in regards to compatibility is a different one.

[ljharb]

You're totally right that the generator-function setup is uniquely complex. but, there needn't be any ESM imports since it exports CJS.

In reality the problem is the nonstandard "module" field that bundlers chose to support :-/

[Robbilie]

you could just remove that module field from the generator-function package.json and my problem would be gone too, i assume :D

[ljharb]

That is certainly possible - you can confirm that by editing it locally.

My concern is for those who are relying on that field working, but if that fixes it for you, I can do some more research.

[Robbilie]

For a short moment i thought it was just a tsconfig flag i had to check to make it work but no.
Removing the "module" field locally makes it work, yes.

EDIT:
i am also trying out other avenues, replacing the outdated pipeline with esbuild, but the resulting nodejs application has 15% more memory usage for some reason and that causes it to frequently run out of memory, so not an option right now…

[electrovir]

Running into the same issue after my package-lock.json bumped my transitive dependency on this from v1.1.0 to v1.1.2.

Workaround

Add the following to package.json:

"overrides": {
    "is-generator-function": "1.1.0"
}