Add an option to enable/disable package.json exports 

I think a very important question for this is: With what default conditions (configurable?) and what behavior for the import/require conditions? Each bundler runs different condition sets from what I know - most have a bundler-specific one, in addition to often using a module condition, on top of import and require.

Also, an important concern for declaration emit is cross-resolution mode compatibility. node and node16 are often close enough that we can gloss over the differences in DT, but with more available configuration, will we potentially need multiple package implementations on DT for different module resolution settings, and, if so, how do we ship (or compose) that? (Or are export map conditions alone sufficient?)

Also ref #29353 where I did what I thought would be some minimal emit changes to create a mode about as flexible as bundlers were at the time. That didn't include any resolution changes :)

With what default conditions (configurable?) and what behavior for the import/require conditions?

import or require based on importing syntax (if we allow require to resolve at all); additional conditions should be configurable.

will we potentially need multiple package implementations on DT for different module resolution settings

This is a problem for us and DT just about as much as it’s a problem for actual runtimes and bundlers consuming implementation packages from npm. What’s in DT should reflect what’s in the implementation package on npm. If the implementation package writes imports that only resolve under bizarre resolvers of the future, it will make sense for the DT package to do the same; it will make sense for users to have broken types under node16 if Node 16 will choke on the implementation package. (This is already basically the world we live in but substitute assumptions about resolution with assumptions about globals.) As of today, nothing I’ve suggested really erodes at the rough cross-compatibility between these existing modes (the changes I proposed to make conventional out of node are very minor). In fact, minimal is the ultimate common-denominator mode, so packages aiming to be as cross-compatible as possible can opt into that (if they take on the extreme limitation of vendoring their dependencies and referencing them with relative paths).

With what default conditions (configurable?) and what behavior for the import/require conditions? Each bundler runs different condition sets from what I know - most have a bundler-specific one, in addition to often using a module condition, on top of import and require.

Just to add onto this (I'm sure this is known from the research put into this proposal, so forgive me if it's already been considered), esbuild has conditions totally configurable (https://esbuild.github.io/api/#conditions, https://esbuild.github.io/api/#main-fields); its behavior was almost changed in the last release which would have changed its defaults too in some scenarios to avoid dual-package hazards (evanw/esbuild#2417), since bundlers can sort of just "import" anything however they want regardless of the syntax (since they control the runtime import behavior internally).

Seems like loaders for Node.js such as ts-node and tsx, or even a future version of Node.js, would possibly want to allow .ts extensions.

Would this be as simple as taking conventional, add the features from node16+, and set noEmit?

I do have some concerns with the approach of enabling .ts extensions without its own flag. Maybe over time noEmit could imply that, the same way that checkJs implied allowJs. But maybe my concerns are not well-founded.

Both minimal and conventional (but not node-legacy) will support resolution to .ts files by specifying a .ts extension in the module specifier. This will be an error, as it is today, unless noEmit is enabled.

I'm curious how this will play out with projects that interpret TS directly; I seem to recall one popular project actually requiring that you didn't set noEmit: true in your tsconfig, but my memory is failing me as to what that is (was it ts-node? a webpack loader? it's been too long ugh)

For anything actually running TS in node at runtime, I think it'd have to be node16 + noEmit allowing direct .ts references.

I do have some concerns with the approach of enabling .ts extensions without its own flag. Maybe over time noEmit could imply that, the same way that checkJs implied allowJs. But maybe my concerns are not well-founded.

Maybe to dovetail with #50133, we should have a allowedNonJsRuntimeExtensions: [".css", ".html", ".es", ".ts"] sort of option.

@jakebailey I believe you’re thinking of ts-loader, but only in “full mode” as opposed to transpileOnly, which has been in the back of my mind to look into, but basically everyone uses transpileOnly

@DanielRosenwasser .ts imports in Node proper would be enabled in nodenext under noEmit and/or whatever other options we pick to make it work in any other mode. We will have to fix the resolution bug I mentioned, which I think we should do soon even if we don’t do anything else soon.

basically everyone uses transpileOnly

Not my last team... 😨 (I think for const enum inlining, and one weird dependency that is only a d.ts file and declares a const enum.)

I feel confident that either it will not matter at all or that the combined will and know-how of me and @johnnyreilly will be up to the task.

As a library author, one thing which would be nice is to allow moduleResolution to be an array, which tells typescript that imports must be valid in all of the listed types. So this would be even more restrictive, as library authors we need to write imports in a way that all the module resolutions work and typescript could help by giving an error. So we could specify moduleResolution: ["conventional", "node16"] and have typescript verify that our imports are correct no matter if the consumer of our library uses conventional or node16.

There wouldn't really need to be any extra special logic in typescript, if moduleResolution is an array typescript would just process each import twice and error if they are not all equal.

I guess its still time to mention TypeScript Should let the Host System do Specifier Lookup let me explain
The ECMAScript Standard Says Specifiers get Resolved on the Language Embedder Side

In Our Case this is TypeScript it self i my self Authored a Lot of Engines so Host Systems that Embedded ECMAScript

my Proposal is finally Merge Rollup or at last its algo under module Resolution rollup into typescript

Rollup is a loader / bundler and a universal ModuleSystem all in One.
Rollup is a collection of hooks and processes to do Specifier lookup and loading then creates a Expression Tree
that is abstract so Universal.

All Existing Host Engines do offer Ways to Manipulate Specifier Resolution

• ServiceWorker (Browser) Request Interception rerouting.
• NodeJS Loader Hooks
• GraalJS Context Filesystem Modification or shim
• Deno Bundle everything always before load and this way Configure Specifier Lookup

Advanced

rollup uses Acorn as AST which is more flexible i suggest changing the Typescript AST with the Acorn one for better Interop in general while there exist Shims for both AST's to work with each other.

the missing parts could get created as Acorn plugin

More Big Proposal

Do not Integrate a Plugin system for specifier lookup kick it all out and go back to only support moduleResolution Classic
and then we do in user-space offer Fuse or something else to provide the right file structure.

also supporting a lookup on package-manager level would be guess able. as mentioned the lockfiles do container specifier resolution at last for the complet module system of the whole project.

I guess Classic + Files containing References or .d.ts only exports is the right way to go. This way we have the resolved parts like with a package-lock.json.

Hi @andrewbranch this really interesting proposal, we have a recurring meeting at TC39 focusing on Tools with folks from(Deno, Parcel, etc..). It would be nice to bring this to the discussion. Send me a DM or fill the form in case you want to participate. :)

about DTS resolution, can we emit code like this to let all declaration brings their own resolution mode instead of inheriting from the project?

// my-library/dist/index.d.ts
export { util } from './utils/index.js' asserts { "resolution-mode": [...] }

Thanks for taking the time to study this deeply. Module resolution is fundamental to the entire web tooling stack so getting it right is valuable and appreciated.

Initial Reaction

We know this is a tough problem space from experience. Inside Bloomberg we have our own runtime environment (everyone seems to be doing it these days) with its own custom resolution semantics. As surmised in Background, just like all the other non-Node runtimes we chose to use "moduleResolution": "node" to approximate our system's resolver. It is not a perfect fit because our resolver is more browser-like and does not do a recursive walk of node_modules directories and does not feature any package.json files. Therefore the proposed "minimal" mode is a closer approximation to our resolver and we would make use of it 👍

Today we handle resolution of bare-specifiers using "paths" to enumerate the full set that can legally be imported by the project. In our system, each project's tsconfig is tool-generated, so this is easy. I'm expecting "paths" will continue to compose nicely with the new modes.

Explicitness as a Guiding Principle

The overall direction of this proposal is to permit explicitness in source code as a way of ensuring correctness. I think this is our North Star and we can use it to resolve some of the consequential issues.

Explicitness matters most obviously in the runtime. As the web platform evolves to allow more file formats to be directly imported (JS, CSS, JSON, Wasm, et al) extensionless imports become a hazard. It's hard to know what import x from "./foo" will mean if you have a directory containing:

- foo.js
- foo.css
- foo.json
- foo.wasm
- foo.<whatever is introduced next>

Bundlers answer this question by implementing priority order. require() also does this. But for the wider web platform, there is no universal precedence ordering of file types. Browsers won't answer this question either; they use explicit mime types and regardless, would not tolerate resolution based on multiple round-trips.

So the preference for our codebases is to avoid betting on a specific bundler's convention and instead sidestep this hazard by ensuring that relative specifiers in source code always use the full source code filename explicitly including its extension.

Importing Declaration Files

in these modes, I suggest that it be legal to write an import type of a module specifier ending in .d.ts.

This is an appreciated step forwards towards permitting and encouraging explicitness 👍

Low priority suggestion: For relative specifiers in "minimal" mode, emitting these extensions in Declaration Emit could also be a useful follow-on step. It's all more clues for the reader and safeguards against the introduction of new extensions in future.

Emitting relative module specifiers ending in .ts

The proposal states that resolution of .ts files will be supported by minimal, but emitting will not. Supporting resolution is highly appreciated and represents another crucial step forwards towards explicitness 👍

However, the ban on emit seems unnecessarily restrictive and is the main thing we would seek to change 🙏

Our internal platform will resolve whatever you point it at. Just like the web. So it would be fine to deploy .ts files and have them import each other. This is primarily desirable from a user's mental model - because the source graph is then coherent, rather than forcing users to reference invisible predicted file names. I agree that writing anything else (e.g. .js) is "nonsensical for the context".

Beyond developer comprehension, using .ts references will also allow us to reduce tooling complexity by avoiding file & specifier remapping. In our system we ban the small number of TypeScript concepts that emit runtime code (enums, parameter properties, etc). So as a concrete example of tooling simplicity, you could imagine our runtime having a development-time file transform loader that makes the TypeScript code executable solely by replacing types with whitespace. This would make sourcemaps redundant.

The counter arguments in the proposal (see "I think much of the demand we’ve heard so far for being able to use .ts-suffixed module specifiers has been misplaced") don't seem to apply here. This use-case is not about working around problems with bundlers. And it's not about shipping the code to multiple environments. It's purely about having freedom.

If TypeScript enforces the noEmit restriction, we can still workaround it in a few ways. But the options are not ideal:

• Option 1 - Fork TypeScript
  • ☹ incurs a small maintenance risk/cost
  • Our pride in shipping 100% Genuine TypeScript™ so far is mildly damaged
• Option 2 - Switch to a third-party TS->JS converter e.g. esbuild or swc
  • ☹ risks divergence from tsc
  • It feels weird to make a big change to our tooling stack for such a small request
  • We love having coverage of TypeScript JS emit in our system. It allows us to study the diffs across our entire codebase whenever there is a Beta release, which lets us feedback issues early such as Bloomberg feedback on TypeScript 4.5 Beta #46382

Conclusion

To sum up, the core proposal is awesome and includes two key features we value highly:

👍 "minimal" resolution
👍 the ability to reference .ts files

The request to allow emit of .ts specifiers is not a showstopper and could be debated/delivered as a follow-on proposal.

Our internal platform will resolve whatever you point it at. Just like the web. So it would be fine to deploy .ts files and have them import each other

@robpalme Just so I'm clear -- your runtime is capable of handling a situation where there are no .ts files on disk, but two JS files are allowed to refer to each other using their original .ts filenames? e.g.

// a.js
import * as b from "./b.ts";

// b.js
export { }

How does it know if there was ever a .ts file in the first place? Or is it just totally agnostic?

Edit: Fixed a critical typo in this example (b.js was previously b.ts)

@RyanCavanaugh I'm describing a different case. Meaning if there is a *.anything on disk, then you can use import foo from "*.anything". Meaning the file extension is not special. It's just files referencing files.

@robpalme did you consider using references the tripple slash once to reference files from files? i do that today and it is a win for me. Google tripple slash typescript If you are not aware of that.

for bundling i simply translate the tripple slash references to imports

@robpalme and I discussed the emit vs .ts imports thing offline. TL;DR -- the scenario he describes above would still be well-supported.

The nuance here is that we would still intend to block .ts -> .js emit via tsc in the case where we see .ts imports, since it's unreasonable to think that a runtime could see a .ts -> .ts import in files named .js and treat that correctly (it's not clear how, and especially unclear why, anyone would implement that). However, API-level operations like ts.transpileModule would not be gated off -- tools would still be free to use the TS API to downlevel/type-strip arbitrary content regardless of the file extensions in import statements.

@RyanCavanaugh there is one thing my thing that implements that i have some engines started with integrated Proposal from TC39 and @DanielRosenwasser and other People that i know that are like minded.

• https://github.com/tc39/proposal-type-annotations

i for example can take .js and .ts files while .ts files will not work if they use special features like enum but as long as they only use type annotations they will run

my.js

import { helloWorld } from './hello-world.ts';
const { log } = console;
log(helloWorld); // => 'Hello World' 

hello-world.ts

export const helloWorld: string = 'Hello World'

In the next JDK Release there will be a Engine Parameter for the JS Interop that enables that for testing. And on the long run i guess more engines will adopt that as it is a clever thing and solves typescripts biggest issue that you can not code something in .ts files that runs as it is.

with that proposal it can run as is as long as it does not use Typescript Superset like enum.

In none NodeJS Based Engines there is no Confusion what import returns it always returns ESModules no matter what the extension says no diffrent behavior in general the specifier behavior is total up to the host and out of the ECMAScript Engine.
Specifier Lookup Resolve and Load happens in the Host that Embedded the ECMAScript Engine.

Frank, your linked TC39 proposal doesn't seem to set a convention for file extensions. It seems like a really bad idea to have one file extension that could mean both:

• actual Typescript language complete with all features that have been established over the past decade or so, or
• JS/ES with type information only

I would hope that we come up with a better convention for naming typed Javascript files. (Is .tjs anything yet?)

@thw0rted mope you did not fully understand let me explain there is a ECMAScript Standard it contains 1 module system this module System is Defined in a Specifier Agnostic Way.

In ECMAScript / JavaScript exists only ECMAScript and JavaScript i did not define that this is how it is. NodeJS Implemented a own loader and module system.

@thw0rted there is no need for a extra extension ECMAScript calls everything in the string that you use to import as "Specifier" the Import Specifier needs to get resolved and loaded by the Host Environment (The one that embedded the JS Engine v8)

so we could make a convention for directory names 👍🏻

cjs/<myx>.js
esm/<myx>.js

that would be more flexible 🥇

the host can simply use the correct loaded based on the indicator in the path

I think I see what you're saying. If we look at support for the TC39 erasable type specification proposal the same way as any other new ES feature, like say the dynamic import() keyword, you'd just have to target your bundler/transpiler emit to your runtime support level -- maybe this will be "ES2023" or something.

In that case, though, .ts should always mean TypeScript, specifically, and .js should always mean ES / JS (at some level of the standard, which must be defined externally). Of course, in a given case, a .ts file could contain only the subset of the TS that also happens to be supported by ES20XX, but it would be a bad idea for x.js to ever import y.ts, much the same as it would make no sense to import y.vue or y.coffee.

@thw0rted deno also imports ts with .ts specifiers there it is wide used and standard

OK, so, TS is a special case, in that Deno can have a JS entry point that imports from a TS file (with a .ts extension), and it will transparently load and run that file without an intermediate transpile step -- and it could not do that with, say, .vue or .coffee or anything else that can, hypothetically, be transpiled to JS.

That still doesn't change the fact that ES20XX Totally Vanilla JS That Happens To Support Some Type Declarations, should carry a .js (or maybe .cjs / .mjs) extension, and .ts should always mean Microsoft (TM) TypeScript (R). Right?

ETA: I just realized, this answers @RyanCavanaugh 's comment from a while back about "it's unreasonable to think that a runtime could see a .ts -> .ts import in files named .js and treat that correctly". Deno would be a case of a runtime that sees a .ts specifier, in a .js file, and really does mean to refer to a .ts file on disk that it intends to execute directly.

Deno would be a case of a runtime that sees a .ts specifier, in a .js file, and really does mean to refer to a .ts file on disk that it intends to execute directly.

My comment above had a critical typo in it. What doesn't happen (to my understanding) is that Deno sees an import of .ts, doesn't find a file with that name, and then instead loads the .js file corresponding to that .ts file.

Resolution to extant files on disk (or files which will eventually exist, if we're talking pre-runtime) is, I think at this point, uncontroversial. Resolution from build outputs back to build inputs is the thing that I am asserting doesn't exist (and shouldn't).

lets all vote and push Tc39 type annotations and drop the .ts exstension and call it a day.

One minor note; internally we’ve been kicking around hybrid (resurrected from #29353) as an alternative name for conventional, lest anyone read a value judgment into the name, or—perish the thought—conventions change.

Sorry for the late post but i got a good idea including aux resource import Maps as source of truth for resolve.
I guess this is why they got designed. At the end it is the smallest Engine Wide convention that is Resolver Loader Implementation interdependent. At the end thats what we do with Chromium Fuchsia and other big Projects. Google uses GN to create import maps for the diffrent systems and then hands thats over to the build system (Runtime) Yes in this case the build system also got a on runtime evaluation to create custom ASM based on build values.

And ECMAScript got a standard for that kind of Build/Runtime Maps. Typescript should adopt the importMaps standard as any other ECMAScript Engine Implementer would do it TypeScript can be rated as Language (Runtime Distribution) that Embeddeds the ECMAScript Engine. So its Role is Host so it should use importMaps no matter what the internals are to create that.

The current handling is more like a IDL Interface Definition Language not like a Runtime Coding Language. I guess Handling Typescript out of General Coding Language view makes more sense then handling it as configurable IDL

, lest anyone read a value judgment into the name, or—perish the thought—conventions change.

Conventions don't change! We're all still manually rendering script tags and using global scope for imports. Right? 😉 window.jQuery forever!