Set esModuleInterop to "true" by default #41139

Activity

1. Ryan Cavanaugh (RyanCavanaugh)

   added

   SuggestionAn idea for TypeScriptAn idea for TypeScript

   In DiscussionNot yet reached consensusNot yet reached consensus

   on Oct 19, 2020
2. RyanCavanaugh commented on Oct 19, 2020

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Oct 19, 2020

   Member

   More actions

   I'll take this as a possibility but we have historically not changed commandline defaults unless the case for it was overwhelmingly strong. This might have the possibility to break people's programs and we would need some very good evidence that it was worth those people encountering that problem.

   👍React with 👍3Reacted by Pelle Wessman, Lemmingh and MarlonPerez-01
3. voxpelli commented on Oct 19, 2020

   

   Pelle Wessman (voxpelli)

   on Oct 19, 2020

   Author

   More actions

   Ryan Cavanaugh (@RyanCavanaugh) Yeah, it's tricky, right now it's causing resentment among non-TS developers who are trying to cater TS users, so current situation is undesirable as well. (See eg also this Twitter thread with me and Matteo Collina (@mcollina) on top of the above GitHub issues: https://twitter.com/matteocollina/status/1305953416217268226)

   👍React with 👍1Reacted by Matteo Collina
4. voxpelli commented on Feb 17, 2021

   

   Pelle Wessman (voxpelli)

   on Feb 17, 2021

   Author

   More actions

   An example where the current default causes confusion and makes people stick with the older non-recommended path: plantain-00/type-coverage#78

   Also had this Twitter conversation with Rich Harris (@Rich-Harris): https://twitter.com/rich_harris/status/1361839944453541892?s=21
5. bmeck commented on Mar 17, 2021

   

   Bradley Farias (bmeck)

   on Mar 17, 2021

   More actions

   I'm a bit wary of using esModuleInterop since how it interacts with node's ESM implementation of default isn't quite compatible. This leads to various conversations about what to do usually ending up with "don't use default exports" as my go to response. Enabling it by default would remove some issues but it seems like a second migration would have to happen afterward if node compatibility was another configuration option.

   👍React with 👍3Reacted by fregante, Lemmingh and Teppei Sato
6. voxpelli commented on Mar 28, 2021

   

   Pelle Wessman (voxpelli)

   on Mar 28, 2021

   Author

   More actions

   I'm a bit wary of using esModuleInterop since how it interacts with node's ESM implementation of default isn't quite compatible.

   Bradley Farias (@bmeck) Can you elaborate a bit on this or provide a link which describes it?

   My impression was that esModuleInterop was meant to increase compatibility?
7. bmeck commented on Mar 30, 2021

   

   Bradley Farias (bmeck)

   on Mar 30, 2021

   More actions

   Pelle Wessman (@voxpelli)

   My impression was that esModuleInterop was meant to increase compatibility?

   It kind of does, but not enough to be completely compatible. Particularly how "default" works still tries to do some magic and things start to get incompatible because of it.

   Given:

   // ./entry.ts
   import * as asNamespace from './dep.js';
   import asDefault from './dep.js';
   
   console.log({
     asDefault,
     asNamespace
   });

   // ./dep.js
   module.exports = {
     __esModule: true,
     default: 'prop named default'
   };

   Compiling to CommonJS will result in the following outputs:

   Node (after renaming .ts to .mjs):

   $ node ./entry.mjs
   {
     asDefault: { __esModule: true, default: 'prop named default' },
     asNamespace: [Module: null prototype] {
       __esModule: true,
       default: { __esModule: true, default: 'prop named default' }
     }
   }

   After TS:

   $ node ./out/entry.js
   { asDefault: 'prop named default',
     asNamespace: { __esModule: true, default: 'prop named default' } }

   Namely, even with esModuleInterop it tries to do some hoisting of the default property if __esModule:true exists that Node won't ever do.

   👍React with 👍3Reacted by fregante, Chengzhong Wu and Beeno Tung
8. voxpelli commented on Aug 25, 2021

   

   Pelle Wessman (voxpelli)

   on Aug 25, 2021

   Author

   More actions

   The #44501 seems to partially implement this as both its module types imply esModuleInterop

   So anyone setting the 'module' in their tsconfig.json to either node12 and nodenext will get esModuleInterop by default.

   A good solution for changing the default without breaking backwards compatibility, but may complicate the uptake of those new types, see eg: sindresorhus/tsconfig#8
9. voxpelli commented on Aug 27, 2021

   

   Pelle Wessman (voxpelli)

   on Aug 27, 2021

   Author

   More actions

   Bradley Farias (@bmeck) Looking at the documentation page for esModuleInterop

   This mis-match causes these two issues:

   1. the ES6 modules spec states that a namespace import (import * as x) can only be an object, by having TypeScript treating it the same as = require("x") then TypeScript allowed for the import to be treated as a function and be callable. This breaks the spec’s recommendations.
   2. while accurate to the ES6 modules spec, most libraries with CommonJS/AMD/UMD modules didn’t conform as strictly as TypeScript’s implementation.

   Turning on esModuleInterop will fix both of these problems in the code transpiled by TypeScript. The first changes the behavior in the compiler, the second is fixed by two new helper functions which provide a shim to ensure compatibility in the emitted JavaScript.

   So while the compiler was fixed to comply with the first point, the ESM spec, as you say, two helper functions was also added to increase compatibility (I guess with older TS-code?)

   Those two helpers seems to be these two ones in tslib:

   __importStar = function (mod) {
       if (mod && mod.__esModule) return mod;
       var result = {};
       if (mod != null) for (var k in mod) if (k !== "default" && Object.prototype.hasOwnProperty.call(mod, k)) __createBinding(result, mod, k);
       __setModuleDefault(result, mod);
       return result;
   };
   
   __importDefault = function (mod) {
       return (mod && mod.__esModule) ? mod : { "default": mod };
   };

   And after compilation your code would roughly look like (assuming importHelpers would also be true):

   // ./entry.ts
   const asNamespace = tslib.__importStar(require('./dep.js'));
   const asDefault = tslib.__importDefault(require('./dep.js'));
   
   console.log({
     asDefault,
     asNamespace
   });

   So I guess, what you're getting at is that you think these two helpers should not be there?
10. bmeck commented on Aug 27, 2021

    

    Bradley Farias (bmeck)

    on Aug 27, 2021

    Last edited by bmeck

    More actions

    So I guess, what you're getting at is that you think these two helpers should not be there?

    I have no opinion on implementation, just that the example above shouldn't behave differently from Node pre/post running TS when trying to match Node. I do not think esModuleInterop preserves behavior as shown above and shouldn't be enabled by default if a 2nd pass of enabling something would create another breakage. I'd rather just have 2 modes of default operation with 2 understood behaviors rather than a long tail mode of legacy prior with esModuleInterop:false default, a second with esModuleInterop:true, and a third with esModuleInterop:true + some flag to make the default export work like Node.
11. voxpelli commented on Oct 30, 2022

    

    Pelle Wessman (voxpelli)

    on Oct 30, 2022

    Author

    More actions

    The #44501 seems to partially implement this as both its module types imply esModuleInterop

    So anyone setting the 'module' in their tsconfig.json to either node12 and nodenext will get esModuleInterop by default.

    Double checked whether this actually shipped, and it did:

    TypeScript/src/compiler/utilities.ts

    Lines 6428 to 6438 in 2bcfed0

    	export function getESModuleInterop(compilerOptions: CompilerOptions) {
    	if (compilerOptions.esModuleInterop !== undefined) {
    	return compilerOptions.esModuleInterop;
    	}
    	switch (getEmitModuleKind(compilerOptions)) {
    	case ModuleKind.Node16:
    	case ModuleKind.NodeNext:
    	return true;
    	}
    	return undefined;
    	}

    So anyone using "module": "node16" or "module": "nodenext" will have their esModuleInterop default to true (but can override it by actively setting it to false).

    Though: This isn't at all mentioned in the docs for esModuleInterop 🤔
12. remcohaszing commented on Feb 15, 2023

    

    Remco Haszing (remcohaszing)

    on Feb 15, 2023

    More actions

    I am strongly opposed to using esModuleInterop and I was shocked to find out this is default behaviour when module is set to node16.

    Many people don’t understand the difference between export default / import identifier from 'module' and export = / import identifier = require('module'). Many people don’t even know the latter exists, though it is often the correct one for their use case.

    esModuleInterop hides this difference for them by generating some interop code. For end user products such as websites or CLI applications, this is not a big deal. For libraries however, this means TypeScript will generate invalid type definitions (#52779).

    I believe users need to be more aware of the code they ship (not write) and its correctness. esModuleInterop opposes this view.

    ❤️React with ❤️2Reacted by Dario Fabricio da silva and Marcel Laverdet