Allow TypeScript files to be imported from npm packages

[kruncher]

I am getting the following error when attempting to import a .ts file from an npm package (byonm):

TypeScript files are not supported in npm packages:

import { foo } from "some-node-module/abc.ts";
foo();

The source of the above error seems to be this: https://github.com/denoland/deno/blob/main/ext/node/resolution.rs#L454

There is a lot that I really like about deno but there are many scenarios where I want to be able to depend upon an entire package of files (scripts, stylesheets, templates, static assets, etc). There are many reasons where I find this to be useful; one such example is that of a reusable component library containing nunjucks templates and .scss files which can then be reused as a package across multiple services.

I would like to be able to reference a node module and then to import TypeScript files as-is and to be able to configure nunjucks to read templates from a directory structure from a package, and to be able to process .scss files where some are imported from a package.

In the node world npm packages quite easily allow for this and I think deno could potentially allow for this with its byonm feature. (As an aside I prefer to reference my own packages from GitHub repositories rather than publishing them to the npm registry).

[dsherret]

Took me a while to find, but duplicate of #16790

In the node world npm packages quite easily allow for this and I think deno could potentially allow for this with its byonm feature. (As an aside I prefer to reference my own packages from GitHub repositories rather than publishing them to the npm registry).

Node doesn't support TS files and so the Node compatibility layer aligns with Node.

I would like to be able to reference a node module and then to import TypeScript files as-is and to be able to configure nunjucks to read templates from a directory structure from a package, and to be able to process .scss files where some are imported from a package.

I believe you should be able to do this, minus the importing the TypeScript file as is. You should be able to import any js file in the package though.

[kruncher]

@dsherret I can appreciate your thoughts on the linked issue regarding pollution of npm with TypeScript modules although I believe it is possible to import .ts modules from other packages given the right configuration.

Instead of using node_modules as a workaround I'd prefer to see some sort of equivalent in deno. Otherwise the irony is that people will end up building deno packages to npm just to be able to have packages when instead it would be cleaner to avoid that altogether by simply having the option to have deno packages.

eg. instead of node_modules being a first class citizen in deno, have deno packages (or even a generalised package mechanism) which deno is able to import typescript scripts from.

Please don't take this the wrong way, this isn't intended to be salty. I am expressing what I would personally like to be able to do with deno.

[lgarron]

Some people encouraged me to give deno 2 a look, so I did. Unfortunately, I find the lack of TypeScript support for npm packages bewildering. 😕

The front page of deno touts it as "zero-config TypeScript" and has a large bold heading claiming "Native TypeScript support". This issue really undercuts those claims, in my view.

I understand that there is a risk of ecosystem fragmentation. But responsibly bundling a project with its proper types is far from zero-config. I've put hundreds of hours into learning how to do so, and even though I'm very good at setting it up I never look forward to it. Until https://github.com/samuelgoto/proposal-optional-types can make the issue moot, I consider it an unnecessary pain for personal projects when there is at least one other runtime that is truly zero-config (bun).

[dsherret]

I recommend shipping TypeScript code to JSR, which is designed to be performant when type checking TypeScript files in dependencies (as long as no-slow-types is followed). npm is not designed to make TypeScript type checking fast.

[lgarron]

I recommend shipping TypeScript code to JSR, which is designed to be performant when type checking TypeScript files in dependencies (as long as no-slow-types is followed). npm is not designed to make TypeScript type checking fast.

Sure. I appreciate the engineering effort that went into JSR.

But I have something that works perfectly for me right now. "You can't do the thing that already works, you have to do it differently" was an issue that led me to abandon deno after writing one non-trivial project in it, and it seems I wasn't the only one. I was hoping that deno 2's pragmatism had turned this around, but telling me I need to adopt a new package manager is not exactly going to spark enthusiasm for me to try deno 2.

Again, I totally respect the tradeoffs! But I'm commenting here to spell out why I don't see any reason to give deno a second look right now, so that you have the explicit feedback.

[dsherret]

You can't do the thing that already works, you have to do it differently

I'm not sure what you mean. TypeScript isn't supported in npm packages in Node or tsc. If you're authoring an npm package, you should be distributing optimized JS and .d.ts files for the most compatibility or you can ship something nobody will use (the obvious exception being private packages).

[lgarron]

You can't do the thing that already works, you have to do it differently

I'm not sure what you mean. TypeScript isn't supported in npm packages in Node or tsc.

I could say the same? npm does not put any requirements on the contents of packages. Many packages include WASM or even platform-specific binaries, neither of which are any more or less "supported" in npm than JavaScript or TypeScript. I've even seen posts talking about using npm to distribute artifacts that aren't intended to be used with any JavaScript runtime.

(In fact, a very large number of libraries do distribute TypeScript in their packages, either as source code or as transformed .d.ts files. But it seems you're aware of that, given your next sentence.)

There's definitely an expectation that most packages will publish their code with some sort of plain JS compatibility. But that comes with a of warts, as this JS can sometimes more semantically broken for some runtimes than the TypeScript source would have been.

If you're authoring an npm package, you should be distributing optimized JS and .d.ts files for the most compatibility

I agree that I should do this, and I've tried to make that clear above.

or you can ship something nobody will use (the obvious exception being private packages).

Apologies, but this sounds empirically false to me. esbuild seems to have no issue importing a package with a TypeScript "main" entry from a TypeScript file. There are obviously tradeoffs, but such packages are by no means impossible to use.

(Presumably other bundlers also have a various degree of support, but I don't use them and haven't tested.)

Anyhow, I don't think you're going to convince me in this issue and it seems clear you're not open to change based on my feedback at the moment. That's fine, it's part of the open-source process. Perhaps more people will chime in here with a similar view and you'll change your mind, or perhaps I'll change my mind as the ecosystem changes. But it's a deal-breaker for me to go back to deno for now.

[dsherret]

It all comes down to TypeScript is not supported in node_modules in Node (even with --experimental-strip-types) nor with tsc. If that ever changes then we'll reconsider. It's better to align with what is the standard practice and not make node resolution even more complex than it already is. Bundlers like esbuild only need to bundle, but tools like Deno need to also do type checking, which doesn't scale well in npm packages.

[lgarron]

It all comes down to TypeScript is not supported in node_modules in Node (even with --experimental-strip-types) nor with tsc. If that ever changes then we'll reconsider. It's better to align with what is the standard practice and not make node resolution even more complex than it already is.

That is certainly a reasonable viewpoint. I still disagree with it, as deno touts "Native TypeScript support" as a primary feature, and even advertises compatibility with non-standard code (JSX) right below. But I can't argue against it being a pragmatic viewpoint for you.

But that comes with a of warts, as this JS can sometimes more semantically broken for some runtimes than the TypeScript source would have been.

I at least want to establish whether deno and/or JSR do better here than most bundlers. Do you know if there's a way to run the transformations that JSR will apply without actually publishing? --dry-run does not produce any useful output for me, and I can't find any docs for an equivalent of npm pack.

[dmint789]

@dsherret I'd also like to know about testing the output of publishing via JSR locally