Deno unexpected token error when importing TypeScript in node_modules with Next.js

[dmint789]

Version: Deno 2.1.7

I'm having an issue with one of my NPM dependencies that has an export like this:

export {
  CUBING_ICONS_CODEPOINTS,
  CubingIcons,
  type CubingIconsId as CubingIconsClassName,
  type CubingIconsKey,
} from "../dist/lib/@cubing/icons/cubing-icons";

I'm getting the following error when importing any of these exports in my Next JS project:

When I directly remove the parts with export type in the NPM package, that error goes away, but then I get an error with export enum CubingIcons. Afaik, export type and export enum are both regular Typescript features, so I would like to be able to use this module in my project. In fact, I have plenty of my own files with export type/interface/enum, and Deno handles them just fine when they're not inside of an NPM package.

[dsherret]

TypeScript isn't supported in Node in npm packages, even with the new typescript mode and so it hasn't been supported in Deno for this same reason. The library authors will need to transpile their TypeScript to JavaScript if they wish to be Node and thus Deno compatible.

[dsherret]

For reference:

$ cat main.ts
import "@cubing/icons/ts";
$ node main.ts
(node:4070) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:4070) [MODULE_TYPELESS_PACKAGE_JSON] Warning: Module type of file:///home/david/dev/scratch/main.ts is not specified and it doesn't parse as CommonJS.
Reparsing as ES module because module syntax was detected. This incurs a performance overhead.
To eliminate this warning, add "type": "module" to /home/david/dev/scratch/package.json.
node:internal/modules/typescript:125
    throw new ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING(filename);
          ^

Error [ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING]: Stripping types is currently unsupported for files under node_modules, for "file:///home/david/dev/scratch/node_modules/@cubing/icons/ts/index.ts"
    at stripTypeScriptModuleTypes (node:internal/modules/typescript:125:11)
    at ModuleLoader.<anonymous> (node:internal/modules/esm/translators:547:16)
    at #translate (node:internal/modules/esm/loader:470:12)
    at ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:517:27) {
  code: 'ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING'
}

Node.js v23.6.1

[dmint789]

For reference:

$ cat main.ts
import "@cubing/icons/ts";
$ node main.ts
(node:4070) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:4070) [MODULE_TYPELESS_PACKAGE_JSON] Warning: Module type of file:///home/david/dev/scratch/main.ts is not specified and it doesn't parse as CommonJS.
Reparsing as ES module because module syntax was detected. This incurs a performance overhead.
To eliminate this warning, add "type": "module" to /home/david/dev/scratch/package.json.
node:internal/modules/typescript:125
    throw new ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING(filename);
          ^

Error [ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING]: Stripping types is currently unsupported for files under node_modules, for "file:///home/david/dev/scratch/node_modules/@cubing/icons/ts/index.ts"
    at stripTypeScriptModuleTypes (node:internal/modules/typescript:125:11)
    at ModuleLoader.<anonymous> (node:internal/modules/esm/translators:547:16)
    at #translate (node:internal/modules/esm/loader:470:12)
    at ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:517:27) {
  code: 'ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING'
}

Node.js v23.6.1

Oh, I see now. For the sake of clarity, does this show that you tried doing the same thing with Node, even with experimental ts support enabled, and it didn't work?

[dsherret]

For the sake of clarity, does this show that you tried doing the same thing with Node, even with experimental ts support enabled, and it didn't work?

@dmint789 yes, exactly.

[dmint789]

For the sake of clarity, does this show that you tried doing the same thing with Node, even with experimental ts support enabled, and it didn't work?

@dmint789 yes, exactly.

Oh, I see. Thanks a lot! I should've thought to try that myself.

[lgarron]

TypeScript isn't supported in Node in npm packages, even with the new typescript mode and so it hasn't been supported in Deno for this same reason. The library authors will need to transpile their TypeScript to JavaScript if they wish to be Node and thus Deno compatible.

If this is the permanent stance of deno, could I advocate for you to update the marketing on your front page?

https://deno.com/

Other bundlers and runtimes have no issue running TypeScript code packages with very sensible semantics and performance. I absolutely understand that some of them do not, but they do not brand themselves as having "Native TypeScript support" and "TypeScript without the hassle" on their front page.

We published this particular entry point as TypeScript because fantasticon can produce TypeScript output directly but not JavaScript. Since most bundlers can handle that, I wanted to keep it simple and didn't add JS transpilation originally. I will look into the best additional toolchain combinations to publish a JS transpilation so that @dmint789 can use it in their project, but this comes with tradeoffs and for me the whole situation is whatever the opposite of "hassle-free" is. 🙁

I absolutely respect deno's stance and the value of normalizing transpiled JS publication packages when they are meant for are meant to be run in a large range of environments. I also adopted deno for a project a long time ago and appreciated how deno was changing the game. But I would like to be candid that I don't think deno is living up to its touted claims, and I hope I still come off as well-meaning and constructive in criticizing your current marketing.

[dmint789]

I'm not an expert on builders, bundlers, JS/TS runtimes, etc., but I also think this would be nice to have. Deno has made my life easier on many fronts, but I also wish it supported pure TS modules (besides JSR).

[dsherret]

Sorry, I just realized this was for specifically in the editor for bundlers and not at runtime.

If this is the permanent stance of deno, could I advocate for you to update the marketing on your front page?

Please be a little more graceful when writing comments on issues.

[dmint789]

Sorry, I just realized this was for specifically in the editor for bundlers and not at runtime.

I'm not sure what you mean. I don't get any errors in the editor, it only happens at runtime (or bundle time? It's a Next JS project, so there's a webpack build step involved). Actually, that made me realize that the title of this issue is incorrect then.

So is the issue not Deno, but rather Webpack then?

[dsherret]

If the code in the npm package is meant for runtime, then the library should be distributing the code as JS with targeted DTS files. This restriction exists in both Node and Deno for the ecosystem benefits it brings because npm packages are not designed to ship TypeScript files performantly. The TypeScript team also heavily discourages the practice.

That said, it's sounding like the bundler isn't correctly bundling the code here for some reason and it wouldn't work in node at runtime either so I'm not sure it's a bug.

[dsherret]

@dmint789 are you able to create a reproduction with next.js somewhere?

[lgarron]

If this is the permanent stance of deno, could I advocate for you to update the marketing on your front page?

Please be a little more graceful when writing comments on issues.

My apologies, I could have worded that with more empathy. I hope you can forgive my tone of my post if you have a chance to take into account its content some day.

[dmint789]

If this is the permanent stance of deno, could I advocate for you to update the marketing on your front page?

Please be a little more graceful when writing comments on issues.

My apologies, I could have worded that with more empathy. I hope you can forgive my tone of my post if you have a chance to take into account its content some day.

That is very passive-aggressive...

@dsherret I'll make a reproducible example.

[dmint789]

@dsherret Here are the steps to reproduce:

1. Clone this repo
2. Open the file client/app/components/EventIcon.tsx
3. Uncomment all of the commented out lines
4. cd client && deno task dev
5. Open http://localhost:3000/rankings/single/333, and the error should be shown

[dsherret]

Ok, so this isn't a deno bug. The error comes from Next.js. I'm able to reproduce with $ npx next dev -p 3000

I'm not sure the exact way to fix it, but it looks like there's an issue here: vercel/next.js#74252

[dmint789]

Ok, so this isn't a deno bug. The error comes from Next.js. I'm able to reproduce with $ npx next dev -p 3000

I'm not sure the exact way to fix it, but it looks like there's an issue here: vercel/next.js#74252

I see. Thanks a lot for investigating this!