I stopped reading here:

The output program T' will throw according to the ES spec.

The ECMAScript specification says nothing about the meaning of module specifiers. Module resolution is the host’s responsibility and is therefore implementation-defined. If the TS compiler can resolve an import but your runtime can’t, that just means your project is incorrectly configured for the target runtime environment and doesn’t say anything about ES compliance.

If you want to argue this behavior is suboptimal, that’s fine, but you can’t use spec compliance as a bludgeon here.

We’ve had thousands of people confused and upset over this for the last 5 years because their valid input programs end up failing to generate valid output.

On the basis of that alone you’re wasting your time, you’re not going to convince me that doing nothing is the appropriate solution, thanks for the comments though.

Stockholm Syndrome ITT.

I’m probably going to regret wading into this, but I wouldn’t frame this issue in terms of language supersets, if the goal is to change how import statements are emitted.

“TS is a superset of JS” means that every valid JS program is also a valid TS program, in a particular sense. It basically just means that a valid JS program should be emitted as-is (or possibly downleveled). It’s quite a weak statement. The only violations of this I’m aware of are things like parsing edge cases as in #33639.

It doesn’t imply that every valid TS program will be emitted as a valid JS program, although obviously such behavior is important. It might not be desirable to emit some line of TS as-is to JS, but doing so doesn’t violate “TS is a superset of JS”.

Okay, let’s say I have three files, foo.ts, bar.ts, and baz.ts.

// foo.ts
import { baz } from './bar.js'

// bar.ts
export { baz } from './baz.js'

// baz.ts
export function baz () { /* ... */ }

Let’s also say that I use a framework which compiles and loads TypeScript on demand, without ever emitting JavaScript. So, the files bar.js and baz.js never exist. In other words, for things to work, I need to import from non-existent file.

• Generally speaking, to whom does this make sense at all?
• More specifically, is TypeScript smart enough to know that when I write bar.js I mean bar.ts, even though bar.js never exists at all? And why would it have to work in this completely counterintuitive and convoluted manner?

I understand that Node is somewhat at fault here for nerfing ESM/CJS backwards compatibility in a way that looks very much the worst of both worlds. Why doesn’t TypeScript:

• (a) fix the broken behavior (by adding extensions in node16 mode)

instead of:

• (b) making it doubly broken (by enforcing the wrong extension in node16 mode)
• and © to add insult to injury, handwaving it all away (with the giant “you’ll get used to it” that is the official documentation on the subject?)

Now let’s say I have the above three files, but I import without extensions (import { baz } from './bar', etc). The framework loads everything correctly, watches files, reloads on edit, even does nifty in-place hot reloading, etc.

Now let’s say I want to publish part of my repo as a library in the form of a portable ES module on NPM. I run TSC, which emits foo.js, bar.js, baz.js. Now these files exist but contain the (invalid according to Node) extensionless imports. So I diligently add the weird .js extensions in the original TS source and what happens?

👏 Reloading 👏 stops 👏

Now I have to re-run TSC on every change, where I previously didn’t, because bar.ts and baz.ts have fallen off the dependency graph and the dev server only sees the .js variants which will go out of date the first time I change the original sources.

Again, please point out the person to whom this affront makes sense, and let them explain how this is not an arbitrary speed bump introduced into the otherwise generally sane modularity and packaging workflow that the JS community had largely settled on before you bought your pseudo-superset a place the ecosystem. I agree that what the spec says is beside the point, because TypeScript is not only non-compliant, it simply generates code that doesn’t work and, to make it work, requires the programmer to write code that doesn’t make sense.

And it requires developers to wrap their heads around numerous implementation details that simply did not exist previously. In my experience, the average JS dev I’ve met already has a hard time wrapping their head around how Promises and async/await are the same thing, you’re just making this harder on people and businesses trying to solve problems by using your platform, which of course is widely lauded as the next best thing since sliced bread. So you can’t even choose not to use it. Congrats, you’ve “won”.

Yall really overdid it with this one, folks. This particular abstraction is so leaky that if it was a ship it’d be sinking. I’d like to say that it ruined my day - only it’s not just one day and it’s not just mine. You know what they say, “don’t look for malice where things can be explained by incompetence”. To which I ask - what is malice, in our industry, other than organized incompetence?

You know that import { foo } from "./foo" works perfectly in the browser, right? Your server just has to respond to GET /path/to/foo with a file that has text/javascript mime type. This is identical to how it has to respond to GET /path/to/foo.js with a file that has text/javascript mime type when using import { foo } from "./foo.js".

Module resolution is the host’s responsibility and is therefore implementation-defined

This is technically true (though in practice, pedantic).

The ECMAScript specification says nothing about the meaning of module specifiers.

This is not true:

Multiple different referencingScriptOrModule, specifier pairs may map to the same Module Record instance. The actual mapping semantic is host-defined but typically a normalization process is applied to specifier as part of the mapping process. A typical normalization process would include actions such as alphabetic case folding and expansion of relative and abbreviated path specifiers.

ECMAScript 2023 § 16.2.1.7

We can go round and round on this if you want, but whether you’re in the browser, you’re in Node, or any other major host of note, in pure ES, import "./file.js" will be valid output and import "./file" will not be.

The whole idea of TypeScript is to add static types on top of JavaScript, not to be a higher-level language that builds to JS.

Not a fan of this backtracking either, 5 years ago this was not the rhetoric that brought me onto TS. TS offered much more, it provided design constructs that were lacking in js and also more expressive syntax (which eventually got added to js). But mostly, the design constructs of access modifiers, statics, interfaces and classes made it possible to design large systems without breaking a sweat. Maybe the differences in the ts implementation and eventual es standard is now deterring the team from adding new features to the language? Case in point, # vs private. legacy decorators. different field initializers. So it looks like the goal post was (silently) moved? Maybe it is also to appeal to the masses of javascripters? I don’t believe this is entirely good. TS used to show what JS could be. Now only babel can do that, but new syntax that compiles through babel is not compatible with the ts language server. So users have to chose between new features with babel on js vs ts with current features. Also babel is limited to whatever is proposed to Tc39, which is a very small subset of what a language can be. Just look to kotlin, swift and even recent versions of c# for inspiration. Languages have evolved a lot in the past few years and TS hasn’t moved much in terms of non-type features. But type features dissapear at compile time and don’t add any value at runtime. So I think excessive type-safety is overrated, moderate type-safety is good. As one wise medium user once said to me, “a sound type system does not maketh a language”. TS is not forward looking anymore, it’s only making what works in js typesafe. I think that was important for full adoption. But I don’t think it should be the only goal. I think it should provide a superset of js.

Regarding this particular mechanic, I mean we have a flag that says “allowESModuleInterop” that transforms imports. So I don’t see why adding another flag, “suffixESImportsOrWhatever” that transforms imports in a slightly different way would be too much of a stretch to imagine. Whether it can accurately do that though, while remapping things like index imports, I don’t know. I think this whole add-.js-at-the-end fiasco is completely unnecessary trouble. Why did we go from nice imports to ugly imports again? Sounds like a step back for mankind.

I’m solutions-oriented though, most times the fastest path to a solution is to write your own code, like below.

Solution

Problem: I want TypeScript to automatically add .js extensions to my imports.

In cases like this I use ttypescript, it basically plugs into the compiler api and lets you run arbitary code as it visits nodes in your AST. Scroll down the readme and you will find a plugin that does exactly what you want, i.e. add .js extensions to your relative imports.

Also, I wrote this hacky but working script to do a one time migration of my code base.

import glob from 'glob'
import { readFileSync, writeFileSync } from 'fs'

glob.glob('src/**/*.ts', (err, matches) =>
  matches.forEach(match =>
    writeFileSync(
      match,
      readFileSync(match, { encoding: 'utf-8' })
        .split('\n')
        .map(l =>
          l.startsWith('import') && l.includes("'.") && !l.endsWith(".js'")
            ? l.replace(/'$/, ".js'")
            : l,
        )
        .join('\n'),
      { encoding: 'utf-8' },
    ),
  ),
)

(js is so expressive these days, you can do all that in a single statement.)

Also, shoutout to tst-reflect which through ttypescript gives much better reflection than anything else we have “officially” atm.

You know that import { foo } from "./foo" works perfectly in the browser, right? Your server just has to respond to GET /path/to/foo with a file that has text/javascript mime type. This is identical to how it has to respond to GET /path/to/foo.js with a file that has text/javascript mime type when using import { foo } from "./foo.js".

OK, so you need to customize the behavior of the server rather than serve a simple filesystem. Proved the point for me.

iT wOrKs pErFecTlY iN tHe bRowSer (with my super special server configuration) - lmao.

@jcalz And it remains a superset if a mapping from the superset to a subset is not a valid subset?

Yes.

Does it remain a superset that can map to the subset of it doesn’t map to the subset, since TS literally is designed to meet this definition as we have already covered and as is mentioned in all of their documentation?

We can ad hoc it as much as we want, it doesn’t meet its technical goals in an ESM context. No amount of cope will change this.

Like I said, if you want to argue the current behavior is suboptimal, that’s fine and I’d even be likely to agree with you. But trying to using the specification as a bludgeon is dishonest here.

Let’s forget about the specification then, given that those using TS dislike the current behaviour, and you are likely to accept it is suboptimal. How about we finally change it!

I really don’t care if I have to use a config file and CLI argument at the same time to make it work.

It doesn’t imply that every valid TS program will be emitted as a valid JS program, although obviously such behavior is important.

If you describe TS as a superset of JS, this is correct (in TS is JS with extra stuff, some of that could make it incompatible). However, the problem is that:

TypeScript adds optional types to JavaScript that support tools for large-scale JavaScript applications for any browser, for any host, on any OS. TypeScript compiles to readable, standards-based JavaScript.

If it should work in any browser, changing ‘./foo’ to ‘./foo.js’ is desirable. Unless you want to take the battle to the browsers, changing the current behaviour of TS looks like the way to go.

On the basis of that alone you’re wasting your time, you’re not going to convince me that doing nothing is the appropriate solution, thanks for the comments though.

Like I said, if you want to argue the current behavior is suboptimal, that’s fine and I’d even be likely to agree with you. But trying to using the specification as a bludgeon is dishonest here.

in my most recent vanilla browser module experiments, they are written in what language do you imagine?

i’ll give you a tip it begins with j and ends with s

On Mon, 29 Aug 2022 at 04:42, C. Lewis @.***> wrote:

Like I said, if you want to argue the current behavior is suboptimal, that’s fine and I’d even be likely to agree with you. But trying to using the specification as a bludgeon is dishonest here.

OK, fine, I take your point with the limited note that it doesn’t say nothing about it, and also point to implementations in practice. There’s enough dishonesty in this whole issue to go around. But yes I will grant you that the spec does not explicitly specify this - we’d probably agree that it could and should.

— Reply to this email directly, view it on GitHub https://github.com/microsoft/TypeScript/issues/50501#issuecomment-1229683923, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABU35SXLH6UQ4F65IEAC5LV3QPQRANCNFSM574CX7OQ . You are receiving this because you were mentioned.Message ID: @.***>

– Kind regards Nikos Katsikanis https://nikoskatsikanis.com Tech Innovation | Podcast Host | Linktr.ee https://linktr.ee/nikosshow

So I don’t see why adding another flag, “suffixESImportsOrWhatever” that transforms imports in a slightly different way would be too much of a stretch to imagine.

Exactly correct. There is no obstacle to adding non-breaking, opt-in support for this.

Noted in the issue, someone actually added this flag and sent in a PR, but it was summarily closed. It is a striking example of organizational deficiency in software. I suspect a single decision-maker or a small group of them are the only obstacles to un-breaking the compiler in this respect.

@jcalz And it remains a superset if a mapping from the superset to a subset is not a valid subset?

Yes.

Really, that’s where we’re going with this to justify emitting broken programs?

I’m not really trying to justify anything. I’m pointing out that this issue isn’t about what the title is claiming to be about. And that talk of supersets is a distraction from your actual concern here.

By the way, I’m not a member of the TS team or anything, so I certainly wouldn’t be in a position to authoritatively justify TS emitting broken programs, working programs, or mp3s of flugelhorn music.

An example of “typical” use does not constitute normative text.

“Include actions such as” is extremely handwavy. It’s neither normative nor actually specifying any algorithmic steps. It says nothing about import "./file" being invalid or import "./file.js" being valid.

Sigh so many people thinking that explicit extensions and full paths are ES requirements is really Node’s fault. They could well keep the CJS resolution mode and make everyone happy. (Same goes for JSON modules—soon people will think assert { type: "json" } is required for JSON modules, just because Node is paranoid about aligning with browsers these days.)

Also, if you use ts-node, you could well make your code run with .js extension imports via the resolver—it’s host-defined behavior at the end of the day.

@egasimus Go off king. Also, sadly, you’ll find several people ITT willing to suck up and make excuses for this problem that could’ve been resolved years ago. Stockholm Syndrome is a hell of a drug.

Worth highlighting Ryan’s comment from the linked response to that PR too:

Maybe we have failed, I don’t know, but we’re going to keep going on this path either way.

Awesome. We’re plugging our ears and yelling “imports are pure JS! imports are pure JS!” even though we can write TypeScript-specific, non-target-legal ./relative imports which are not pure JS and do need to be transformed.

Yes, you are failing, but the beauty of software is we can always fix it. I’m still holding my breath.

@ctjlewis i added an option in my pull req: https://github.com/microsoft/TypeScript/pull/47436

@jcalz And it remains a superset if a mapping from the superset to a subset is not a valid subset?

Really, that’s where we’re going with this to justify emitting broken programs?

Like I said, if you want to argue the current behavior is suboptimal, that’s fine and I’d even be likely to agree with you. But trying to using the specification as a bludgeon is dishonest here.

OK, fine, I take your point with the limited note that it doesn’t say nothing about it, and also point to implementations in practice. There’s enough dishonesty in this whole issue to go around. But yes I will grant you that the spec does not explicitly specify this - we’d probably agree that it could and should.

Though, to be clear, import "./a" is not even target-legal for Node target. So I mostly dispute that there’s a substantive issue with my statement.

Thanks for the responses!

The solution I went for was using the create vite vanilla TypeScript template. Under the hood it uses Rollup. In the process, I also discovered pnpm. Overall, I am pretty happy with my initial results.

I have a functioning starter project, and I can easily transpile the following TypeScript:

import Foo from "./foo.ts";

into functional JavaScript that does what I need it to do.

For those interested, here are links to info on Vite, Rollup, and pnpm.

I also checked out @arendjr’s suggestions of Deno and Bun. They looked like interesting projects, but I was a bit nervous to move that far away from the npm/node ecosystem. Choosing ‘vite’, ‘rollup’ and ‘pnpm’ seemed like a more moderate choice.

The documentation already explicitly dis-recommends moduleResolution: "node"

IMO,

1. “node will emit code that doesn’t run on Node” is a real issue.
2. “nodenext will refuse to emit code that doesn’t run on Node, nor will it auto-fix your code” is a non-issue. I have forked an ESLint plugin (npm) to auto-fix missing extensions, although I have never actually needed it since auto-import already does the right thing.
3. If 2 was indeed an issue, “bundler is fine with emitting code that doesn’t run on Node, so you can have a separate step that fixes it” solves the issue.

I think 1. can be resolved by deprecating "moduleResolution": "node". All future es* targets should default to either "moduleResolution": "nodenext", or some variant of "nodenext" stripped of node_modules (https://github.com/microsoft/TypeScript/issues/37971), rather than

Classic if module is AMD, UMD, System, or ES6/ES2015; Matches if module is node16 or nodenext; Node otherwise.

Maybe there is also some documentation fix to explain points 1/2/3 better.

Now I have to re-run TSC on every change, where I previously didn’t, because bar.ts and baz.ts have fallen off the dependency graph and the dev server only sees the .js variants which will go out of date the first time I change the original sources.

This is untrue. Go to definition et al go to the TypeScript source file. Bundlers in watch mode work the same way they always have.

Well, I’m happy that after 8 years, at least we have an open issue to complain on. If nothing else, it’ll make me feel better when I come back here again in 6 months.

Don’t worry, I never let them hear the end of it. Thankfully, we have Bun now. Use that for TypeScript + ESM builds.

@arendjr Thanks for the recommendation. Yes going to try Deno and use it from now on.

The response from Node devs was that this has been discussed before and they aren’t going to do anything with paths with no extensions. Their docs clearly state that ESM relative import paths must have a .js or .mjs extension. I think they could resolve these extensionless paths without difficulty but here we have it.

and it could also be solved with custom transformers, but they are not public. don’t know why they exist at all when they are not exposed