Baselines: export = a reordered; ESM side-effect import replaces export {}

[RyanCavanaugh]

CJS declaration ordering + ESM side-effect emit changed. export = a reordered after declaration; ESM side-effect import replaces export {}.

Affected Files

``
conformance/nodeModulesAllowJsExportAssignment(module=node16).js.diff
conformance/nodeModulesAllowJsExportAssignment(module=node18).js.diff
conformance/nodeModulesAllowJsExportAssignment(module=node20).js.diff
conformance/nodeModulesAllowJsExportAssignment(module=nodenext).js.diff

[ahejlsberg]

New declaration emit seems reasonable and closer to the original source.

[RyanCavanaugh]

Agreed. Drilling in, the diff is

 //// [index.d.ts]
-export = a;
 declare const a: {};
+export = a;
 //// [file.d.ts]
-export = a;
 declare const a: {};
+export = a;
 //// [index.d.ts]
-export = a;
 declare const a: {};
+export = a;
 //// [file.d.ts]
-export {};
+import "fs";

So we move export = around, and retain import "fs"; which means we don't need export {} anymore to preserve moduleness.

[jakebailey]

Shouldn't we be eliding that unused import?

[RyanCavanaugh]

@weswigham / @andrewbranch any thoughts? Input is

// @target: es2022
// @module: node16,node18,node20,nodenext
// @declaration: true
// @allowJs: true
// @checkJs: true
// @outDir: out
// @filename: subfolder/index.js
// cjs format file
const a = {};
export = a;
// @filename: subfolder/file.js
// cjs format file
const a = {};
module.exports = a;
// @filename: index.js
// esm format file
const a = {};
export = a;
// @filename: file.js
// esm format file
import "fs";
const a = {};
module.exports = a;
// @filename: package.json
{
    "name": "package",
    "private": true,
    "type": "module"
}
// @filename: subfolder/package.json
{
    "type": "commonjs"
}

[andrewbranch]

Argument for preserving

If you had told me we started preserving side-effect imports in declaration files at the same time we stopped synthesizing type reference directives in order to better preserve the module graph and any global declarations that enter the program via that side-effect import, that would have sounded reasonable to me—if the user has already written import "fs" because it made some new globals available, maybe it's unintuitive to strip that and make them write the more esoteric <reference types="fs" preserve="true" /> instead.

Argument for eliding

import "fs" has runtime emit and <reference types="fs" preserve="true" /> has declaration file emit. Keeping their emit scoped exclusively to the domain they're intended to work on gives the user more granular control of how their declaration files come out—if side-effect imports emit to declaration files, there's no way to write a declaration that affects only the runtime module graph. Lots of polyfills and other side-effect-only packages don't even include types, so we don't really want declaration files to start including extra unuseful and potentially unresolvable imports.

Takeaway

I think we should continue eliding like Strada did. I think the argument for preserving might be weaker than the argument for eliding even without considering conformance to Strada. It definitely doesn't seem strong enough to merit overturning what Strada has always done.

[andrewbranch]

In chat, @weswigham pointed out that the elision behavior is unique to the JavaScript declaration emitter in Strada, which I think changes my conclusion a bit. Doing things the same between TS and JS seems good, and standardizing on Strada’s TypeScript declaration emitter as the north star behavior makes sense. This might be a "wontfix" after all.