I can't load through commonjs in Node

[basedwon]

I tried a number of ways to require it but to no avail, I literally can't use file-type on Node because of this. It looks like you just need to remove the module prop from the package.json.

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/.../node_modules/file-type/index.js ... Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /Users/.../node_modules/file-type/package.json.

[basedwon]

Actually, it's not that simple. I tried removing the module type, changing .js to .cjs and .mjs and even running node with the --input-type module flag, and still it's yelling at me that I must use import. How have others used this package in node? It doesn't even seem to be possible currently.

[Borewit]

/**
 * Import 'file-type' ES-Module in CommonJS Node.js module
 */
(async () => {
  const { fileTypeFromFile } = await import('file-type');

  const type = await fileTypeFromFile('fixture/fixture.gif');
  console.log(type);
})();

Full working example: https://github.com/Borewit/file-type-example/tree/master/commonjs

[basedwon]

Ok, thank you, that does work, however it's unlike every other package in node that import synchronously. I'm building a lib that works on both browser and the server. I already load fileType in the browser fine, but this means I can't just have it switch automagically based on context (

[Borewit]

You can also switch, like file-type, to an Node.js ES-Module. To keep both worlds happy is tricky, in theory ES-Module is better foundation for that, but it is a bit of painful transition.

[basedwon]

I've been doing just fine with using webpack to handle ES/commonjs importing on the frontend. Therefore all my libs are written in commonjs and all my frontend is ES. This has been a nice separation, been doing it for a while. I'd have to adjust 100's of files and it's just not worth it. I was literally just porting file-type over to commonjs format and then I had the same issue with this strtok3 lib. I'm just not a fan of enforcing ES mods, I guess if you like to write in that style. But it looks like it's mostly typescript which could be transpiled to common format, couldn't it?

[Borewit]

Hi @Arrron777, I am not the owner of file-type, that is @sindresorhus. It is part of his masterplan to migrate to ES modules. Which I thinks is a brave and drastic change. With my own modules I am a bit more conservative. file-type depends on modules like strtok3, peek-readable, for which I ES-Modules candidates so far. Porting music-metadata to an ES-module is still work in progress. But I hope ES-module allows me to combine music-metadata and music-metadata-browser into a single module on the long run.

But it looks like it's mostly typescript which could be transpiled to common format, couldn't it?

Well, my modules are written in TypeScript, and it is not a matter of just changing the target and you're done. E.g. changes migrating strtok3 to an ES module.

I don't think there is a perfect solution here, but the module systems grew very fast and become a bit of mess with different flavors. ES module seems to be now accepted as the formal module system for Node.js and browser. Sometimes you have to a take step back to be able to step forward.

[basedwon]

@Borewit thanks for the response. I ended up rewriting file-type and strtok3 to normal commonjs for now. Obviously that's not a permanent solution, but I need sync import, otherwise I'd have to use global vars which is bad for an npm package. I'm not a huge fan of typescript so I don't really know what's involved in making it's artifacts commonjs friendly. But I am building a lib that works in both browser and server. And all the other packages I use can be required or imported. That's because they're written in commonjs and then webpack handles both. The problem is that node doesn't handle both. So, I'd think the smart move would be to transpile the typescript to commonjs. Otherwise node users just can't use your library. And most usecases they're not gonna want to do an async import.

I've seen some projects that will have an export in the package.json that switches based on node/browser and then you could provide both variations. But ESM is just not Node friendly at this point. I know people want to say import instead of require but to me that's no reason to force something on other developers. Bottom line is that making a package ESM only makes it unusable by Node.js devs. That's not just going backwards, that's a complete halt/fullstop. Since I was able to rewrite the modules to commonjs in less than 30 mins and it seems to work, it shows that those modules aren't even using anything special from ESM.

Anyway, those are my thoughts on the matter, I do respect your work on these projects. I'm just speaking for the Node.js community when I say: if it aint broke, don't fix it : )

[basedwon]

Just saw this in @sindresorhus article
https://nodejs.org/api/packages.html#packages_dual_commonjs_es_module_packages
He says in there that he wants to not offer dual support and "just rip off the bandaid" -- well, that's not a bandaid, it's stitches holding the body together and ripping it off will cause sudden death.

Please consider the dual method. I like file-type, but honestly I'll just fork it to a dual method if I have to.

[sindresorhus]

You are of course free to dislike ESM, but that doesn't mean it won't happen.

Dual packages come with their own downsides: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c#gistcomment-3850849

I have no plans to switch any of my packages to be dual.