Vite 8 incompatibility due to cjs default export

[revosw]

Vite 8 released last week. See vitejs/vite#21890 for context. I respect #432 being rejected. I just wanted to contribute to the discussion, and hopefully one day we get to a point where you would consider publishing as esm.

When using Rolldown, which Vite uses as bundler, it is recommended for each library to not export default from a cjs file.

For now, inconsistentCjsInterop: true does work by restoring the old behavior. However, this is deprecated as per the migration guide. So one day it won't.

export default defineConfig({
    legacy: {
        inconsistentCjsInterop: true,
    },
});

[Bossa573]

just curious, majority of the packages on npm are not esm, how the vite comunity handle this? (I don't use Vite at all therefore no such idea)

it's not practical that "just stop using any non-esm packages", and I don't think it's practical either for asking the package owner one by one and hopefully they migrate to esm, right?

(note that i'm not opposing esm, it just sounds weird)

[revosw]

Imagine you import from a cjs module

// import named
import { phone } from "phone"

// import default
import phone from "phone"

There are two ways default exports can be represented in cjs. One is simply that module.exports is itself the default export. This is how nodejs by default handles cjs modules

exports = {
	phone,
	countryPhoneData: country_phone_data_1,
}

When doing import phone from "phone", this means phone is not the phone function, but the entire object being exported. So to call the phone function, you must do phone.phone(). But if you were to say exports = phone, now you won't be able to access countryPhoneData, as you are only exporting the phone function.

If we want to be able to access all exports, but still have the convenience of default exporting a specific symbol, typescript must be configured to use esModuleInterop: true in tsconfig.json, or in Vite 8.0's case, inconsistentCjsInterop must be set to true. This makes typescript (or Rolldown, Vite's bundler) emit __esModule: true on module.exports, and all default exports of cjs modules will be exported through the default property

Object.defineProperty(exports, "__esModule", { value: true });
exports.default = phone;
exports.phone = phone;

Without inconsistentCjsInterop: true, Vite 8.0 treats all CJS modules as the default export being exports, and not exports.default. The phone module relies on the __esModule: true and exports.default behavior, and so that's why "phone" is not a function is printed when trying to call phone() without __esModule: true

This next point is not really against cjs in a way that affects the phone library, but cjs is inherently dynamic. You can define the export of a cjs module to be anything you want

exports = require(process.env.NODE_ENV === "production" ? "prod-module" : "dev-module")

This means it's impossible to say without an accompanying .d.ts file or extra annotations what is actually exported from the module, if you conditionally export stuff. With es modules, all exports can be statically known without any fragile heuristics, and autocomplete can be made without .d.ts files or extra annotations

The vite community hasn't really had to deal with the cjs inconsistency, which is evident from the output of the typescript compiler in esModuleInterop: true mode:

const country_phone_data_1 = __importDefault(require("./data/country_phone_data"));

Where __importDefault conditionally imports the default based on __esModule

var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};

From what I gather, Vite 8.0 is trying to set a precedent. __esModule: true was introduced back in 2015 when people were eager to use import ... from ... before it was available in browsers and nodejs itself, transpiled down to require() by Babel. Every runtime now supports es modules, therefore __esModule: true isn't really necessary anymore. It's just there because the ecosystem hasn't embraced es modules without the extra interop bandaid

[Bossa573]

The phone module relies on the __esModule: true and exports.default behavior, and so that's why "phone" is not a function is printed when trying to call phone() without __esModule: true

It sounds like the main issue is this one, instead of using cjs module with Vite, is that correct?
I'm not sure which part of the module relies on the __esModule: true and exports.default as I am not the maintainer of that part.

[revosw]

Yep, it even looks like TypeScript 7 itself will not have esModuleInterop as a tsconfig option, which means it won't be possible to emit packages with Object.define(exports, "__esModule", { value: true })

$ npx tsc --noemit
tsconfig.json:7:22 - error TS5107: Option 'esModuleInterop=false' is deprecated and will stop functioning in TypeScript 7.0. Specify compilerOption '"ignoreDeprecations": "6.0"' to silence this error.

7   "esModuleInterop": false,
                       ~~~~~


Found 1 error in tsconfig.json:7

The effect of this is that it will no longer be possible to have a cjs module specify a default export, and thus will be a breaking change for anyone doing import phone from "phone" then calling phone() directly.

From what I understand, if the package is kept on "module": "commonjs", this package will be stuck using typescript 5. If the package is edited to emit "module": "esnext", the package can continue to provide a default export, however at the cost of any commonjs consumers not being able to use this version since they need to upgrade to es modules.

So the path I would do is to publish a v4 of phone with "module": "esnext" as the output. I would also install "typescript": "6.0.1-beta" and try to compile with that, just to see which compiler errors you are getting, because there are incompatibility checks in v6 that will surface any to-be errors in v7

[Bossa573]

I'm okay to explore for sure, but not sure if there's a way for commonjs user to use.
I know there are some packages already rage-quitting cjs such as change-case, just wonder if there's a more gradceful way.

(From nodejs 22 user can already import esm module directly without load-esm hacks though)

[revosw]

One could do dual publishing, although I've heard/read that it's been a bit of a pain I assume it's a valid solution
https://mayank.co/blog/dual-packages/

[Bossa573]

i will check that dual packages method,
however as the npm community is slowly moving toward esm (nodejs support esm out of the box, vite issue, ts7 issue), i don't think the esm direction is off.

at the same time i'm thinking of maintaining v3 (cjs) and v4 (esm) at the same time for a year or two,
new features will be only on v4, but only for the phone numbers rule, v3 would be getting the updates for sure, so that i don't need dual package