TS Build api failed when using node ESM module (mjs)

[stevebeauge]

🔎 Search Terms

ESM ts.sys undefined

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about modules

⏯ Playground Link

https://github.com/stevebeauge/tsc-api-esm

💻 Code

import * as tsc from "typescript";

const tsSystem = tsc.sys;

console.log({ tsSystem });

🙁 Actual behavior

If I transpile this code into CJS and run node index.cjs works as expected (tsc.sys is defined).

If I transpile this code into ESM and run node index.mjs the code does not works as expected (tsc.sys is undefined).

🙂 Expected behavior

tsc.sys (System) should be available in CLI tools, whether the output is ESM or CJS.

Additional information about the issue

The issue occurs when trying to create a CLI tool that require parsing tsconfig files, including potential "extends". Typescript provides an API for that.

However, my cli tool requires to be ESM because of some imports not available as CJS.

Repro steps (using pnpm but it does not matter):

git clone https://github.com/stevebeauge/tsc-api-esm
cd tsc-api-esm
pnpm i 
node index.cjs
node index.mjs

When using cjs : OK
When using ESM : KO

My investigations leds me to :

TypeScript/src/compiler/core.ts

Line 2748 in 80ab111

&& typeof module === "object";

It populates the tsc.sys when the function "isNodeLikeSystem" returns true. However, the test expect to have module be defined (which is true in CJS, not in ESM).

[jakebailey]

The isNodeLikeSystem thing is a red herring; our code is CJS and so node will load it as such. The module type of the importing code cannot affect how other modules are loaded.

The actual problem here is the use of a native namespace import to import TypeScript (without the ES module interop helpers, as you have written .mjs directly). If you write import ts from "typescript";, your code will work as expected.

I'm not sure why node isn't straight up rejecting import * as ts from "typescript". It used to error and force the use of a default import as our module is not one that can be statically analyzed. I hit this myself in dtsBundler.mjs in our own repo. But, I'm not having any luck getting that error to appear again even on old versions of Node and TypeScript.

[stevebeauge]

I'm not sure to understand the difference between import * as tsc from "typescript"; and import tsc from "typescript";

I confirm it work using this other syntax, so is in my cli tool. I close the issue, as it's probably not a bug.

Many thanks for highlighting the wrong import.

[jakebailey]

That being said, if we actually do want the namespace import to work (which, I really do remember not working beforehand at all), there's something weird going on here.

Adding logging to out output bundle, I can very clearly see it being properly constructed and assigned, and yet it comes out the other end undefined:

node index.mjs
Using Node system
module.exports is object
sys is object
{ tsSystem: undefined }

[jakebailey]

A small example:

// mod.cjs
const exported = { value: 1234 }
console.log("hello from mod.cjs! exported =", exported);
module.exports = exported;

// index.mjs
import * as asNamespace from "./mod.cjs";
import asDefault from "./mod.cjs";

console.log({ asNamespace, asDefault });

Prints:

hello from mod.cjs! exported = { value: 1234 }
{
  asNamespace: [Module: null prototype] { default: { value: 1234 } },
  asDefault: { value: 1234 }
}

So, what I thought was weird was in fact not (and I should have logged the whole object and not ust one prop). When you do the namespace import, you get an object with only default, so asNamespace.value is undefined (like ts.sys). See also: https://nodejs.org/api/esm.html#commonjs-namespaces

But, I can't actually seem to get TS to emit some sort of static error to complain about this:

Nor can I figure out how to get Node to emit some error here.

[jakebailey]

Going to reopen this just because I want to still investigate some way we can help people avoid this footgun.