Include example with TS 5.0 --moduleResolution bundler

[sharky98]

Hello,

With the arrival of TS 5.0 option --moduleResolution bundler, could you add an example using this value? I am mainly confused on what to put in package.json field main and equivalent exports since we are not producing .js files?

Regards,
Bruno

[andrewbranch]

Hi Bruno,

This repo was intended to show examples for how libraries, who publish JS files to npm, can support users who use a variety of (maybe incorrect) moduleResolution configurations. Those libraries should always produce .js files, and should not compile with --moduleResolution bundler themselves. For users who have --moduleResolution bundler set, node_moduels packages will resolve identically to how --moduleResolution nodenext would behave in a .mts file. I don’t think there’s anything unique there for this repo to show. Does that answer your question?

[sharky98]

Thanks for your answer. I don't know if it answer my question; I might have to re-read a few times 😅!

Basically, what I was looking for is to create TS packages (in the sens of no JS files) to publish in a private (localhost in fact) repository to reuse around in my own projects. Obviously my other projects are also TS projects and down the chain one will be responsible to do the build (bundle, compile, transpile, or whatever that project needs).

I was hoping that my project doing the build could use the TS file from the node_modules package directly and not use the pre-made ESM or CJS files and mash them again. A bit like having the TS file directly in the project (either duplicated or in a monorepo workspace with pnpm).

Maybe I am overthinking it. Maybe the docs aren't clear on the use case for --moduleResolution bundler (in fact, I see nothing in the docs, handbook or tsconfig reference about it; there is only the TS 5.0 release note). Maybe I am trying to use a bit too much bleeding edges (or strict) options not compatible with existing tools. In any case, this whole module thing in JS/TS ecosystem is driving me nuts 😂¹!

For the moment, I only got a re-use inside a monorepo working using both --moduleResolution bundler and --allowImportingTsExtensions.

I'll close this since the goal of the repository was not really what I was asking.

Footnotes

1. A bit of ranting (to let of the steam...) Don't even get me started on a Webpack config written in TS trying to import a plugin... Trying all possible options import = require() const = require() import * as This from 'this' import This from 'this' import {This} from 'this' to get type hinting work in the IDE, only to complain it is not constructible later on with the new This(). Then, its just iterative process (including modifying tsconfig.json) to get the IDE, ESLint, tsc, ts-node and nodejs all agrees on something that works! But most of the time, I end up having a config that work to get the end result even though someone in the chain is whining something isn't right. ↩

[andrewbranch]

You can just point your package.json "main" or "exports" to the .ts files, and consumers with --moduleResolution bundler should be able to pick those up just fine. However, if your overall project size is big enough, note that .d.ts files are more efficient for the type checker to consume, so the structure you’re envisioning may come with a bit of a compile-time performance penalty.

to get type hinting work in the IDE, only to complain it is not constructible later on with the new This()

When this happens, it means either your own tsconfig is wrong, or the package you’re consuming has typing/package.json problems. This is why I made https://arethetypeswrong.github.io. Next time you hit a problem like that, I’d encourage you to run it, and file an issue with the library if it shows configuration issues.

I see nothing in the docs

I’m working on them; see microsoft/TypeScript#52593 for tracking and https://gist.github.com/andrewbranch/79f872a8b9f0507c9c5f2641cfb3efa6 for the in-progress draft.

[sharky98]

Thank you very much for this information. It will be greatly helpful!