target node14.6.0 emits unsupported code

[Shinigami92]

faker-js/faker#1052

We set out target to ['es2020', 'node14.6.0'] as node v14.6 is the lowest version we want to support based on https://kangax.github.io/compat-table/es2016plus/#node14_6

In the issue you can see that everything below node 14.13 is failing in the build step
(I assume) related to that, we got multiple issue reports about that Webpack and Cypress now fails when using FakerJS

---

This can be somewhat also be relevant for Vite and other Vue/Vite ecosystem packages 👀

[hyrious]

I believe this is because node's support for simulating esm named exports was just added in node14.13 (#35249), which causes your @esbuild-kit/esm-loader failed to work. To make it clear, I'll take the following code for example:

// lib.js (commonjs)
exports.a = 42

// index.mjs (esm)
import { a } from "./lib.js" // only works in >= node14.13

Before 14.13 you could only do import all from "./lib.js"; let { a } = all. Unfortunately @esbuild-kit/esm-loader contains this kind of named importing a cjs dependency in their code so they do not support these node versions.

[Shinigami92]

@hyrious 👀 are these info for Evan or can I do something on my side to workaround this?
I would assume that an error is thrown by esbuild if it cannot transform code to node14.6 if explicitly defined or it just works and do what was requested via the target property

[hyrious]

No, I mean one tool you're using (esno) does not support node < 14.13, that's why the check failed. It even does not enter the process of doing build/transform in esbuild.

I'm trying to give you more detailed info:

1. You're running the build script with esno, which is now an alias for tsx.

2. tsx runs your script with an esm loader @esbuild-kit/esm-loader, which has this kind of code:

   import { resolveTsPath } from '@esbuild-kit/core-utils'

   This code is still look like this after bundling, you can see the final package file from unpkg.

3. So what's wrong with this code? It cannot run in node < 14.13 because there's no named exports support for commonjs modules, and @esbuild-kit/core-utils is exactly a commonjs-only module.

In conclusion: there's nothing you can do to workaround this unless you make a patch to the @esbuild-kit/esm-loader to support node < 14.13 or switch to another tool. In fact I guess supporting some old patch versions doesn't matter a lot.

[Shinigami92]

So I'm a bit confused now...
Do I need to switch to tsx instead of using esno, because esno uses some "with automated CJS/ESM mode and caching."?
Or do I need to use node and transpile our bunlde.ts to bundle.js before I run node ./scripts/bundle.js?

[hyrious]

Do I need to switch to tsx instead of using esno, because esno uses some "with automated CJS/ESM mode and caching."?

Have you read its source code? 🤣

Or do I need to use node and transpile our bunlde.ts to bundle.js before I run node ./scripts/bundle.js?

This is exactly a workaround to pass your CI check! If all your need is that, go for it.

[evanw]

Thanks for investigating. Closing because this is not a problem with esbuild.

[Shinigami92]

Uhm... I now compared the dist from main branch and the dist from the PR (that now uses plain node and normal js, not ts or anything like that) ... and the result is the exact same 👀

So I'm not sure if this was the issue 🤔
IMO it's sadly not solved yet

[Shinigami92]

The funny thing is, that if I switch target to node12, it definitely emit at least one file differently

Seems like to transform some nullish coalescing or so 🤔

So could it be that prior to node v14.13 something needs to be adjusted here? I'm not sure how esbuild maps which feature is allowed for which target.