Sharing code with browsers: .ts extension issue

[ondras]

Hi,

for my current Deno project, I tried re-using some of the existing code initially written for a browser. This works:

import stuff from "../browser/browser-module.ts";

However, I run into issues when the browser-module depends on other files:

// browser-module.ts
import another from "./another.js";

...because Deno requires the use of .ts extension. The whole browser-side setup works either with .js (as my .ts files are compiled down to .js) or without extensions at all, because TSC seems to be smart enough. But I am unable to use .ts (required by Deno) with TSC -- it fails with

An import path cannot end with a '.ts' extension.

Any ideas? Thanks!

[artisonian]

Are you compiling with tsc? If so, I'd expect it to fail, but Deno's runtime should recognize both .ts and .js modules in the same file (for example, I can import mustache.js from unpkg without issue).

[ondras]

The client side is compiled with tsc (set of .ts files =>set of .js files) and -- optionally -- bundled with rollup for production.

Deno's runtime should recognize both .ts and .js modules in the same file

Do I understand correctly that you suggest compiling/bundling the client side with Deno as well (via deno bundle)? I would probably not need any .js files at all in this case. But I would have to rely on Deno's bundling (rollup seems to do a better job here) and also I would lose access to some tsconfig.json configuration options (target, for instance).

All in all, I do not think that compiling/bundling the client side code with Deno is the proper way to go.

[ondras]

The browser has an ecmascript module loader, so why bundle?

To reduce the number of HTTP requests.

I think he's suggesting not compiling and not bundling at all and just referencing the .ts files directly

tsc is unable to resolve imports that use the .ts extension. (Well, at least when I tried back in 2020. This issue is old and things might have changed.)

[artisonian]

I'm not suggesting using deno bundle for client-side code (see #3793 for an extended discussion), but rather trying to understand your build process. If you want to include .ts modules compatible with both Deno and browsers, your browser build pipeline would need to transform those import statements for you. Otherwise, you might be able to use import maps on the Deno side to resolve bare imports.

[ondras]

. If you want to include .ts modules compatible with both Deno and browsers, your browser build pipeline would need to transform those import statements for you.

Right! Ideally, I would love tsc to accept .ts imports as well (they are TypeScript, right?). But I am not aware of any way to do so.

Otherwise, you might be able to use import maps on the Deno side to resolve bare imports.

This sounds like an interesting option. Will give them a try.

[justinmchase]

There is a huge discussion on this in the typescript repository and despite every user in the world wanting them to support .ts imports they will not do it because it violates a principle that they are sticking to for better or worse. No matter how many times you read the justification it won't make sense but the short version is no there is no supported way in the tyepscript compiler itself to support bare .ts imports.

[ondras]

Deno's runtime should recognize both .ts and .js modules in the same file

It does, but does not really work with transpiled files; they have type information stripped from them. Here are two possible approaches, both failing at various places.

1. using .ts in import specifiers:

// deno-server.ts:
import { SomeType } from "./browser/some-type.ts"; // server side: works when compiling with Deno

// browser/some-type.ts:
import other from "./other.ts"; // client side: fails, tsc does not expect .ts

2. using .js in client-side import specifiers:

// deno-server.ts:
import { SomeType } from "./browser/some-type.js"; // server side: fails, this is a transpiled file without type information

// browser/some-type.ts:
import other from "./other.js"; // client side: works

[ondras]

To sum things up: with Deno, I cannot import a tsc-compiled dependency that has other dependencies.

[kitsonk]

While this evaded me before now, I think we will be able to fix it in #4538 for Deno.compile(). Would a fix there work for your @ondras?

[ondras]

Would a fix there work for your @ondras?

No, I am not doing Deno.compile(), I am trying to deno run some code that has transitive client-side dependencies. This is a sample file: https://github.com/ondras/rri/blob/master/server/player.ts

These direct dependencies go to ../src/*.ts which is OK, but their additional dependencies (example) are declared with .js extensions, because that is what TSC needs. So I am currently generating a large importmap that converts *.js to *.ts, so that Deno can process these import "x.js" statements as well. Not really optimal, but probably the only way to go.

All in all, I do not think this is a bug in Deno, because I do not see a proper Deno-based solution for this scenario. All my source files are TypeScript, so they all shall have a .ts extension. Unfortunately, the need for client-side TS compilation is forcing me to use .js, Deno-incomaptible.

[lucacasonato]

Is anything here actionable for us? If not I would like to close and move the discussion to https://github.com/denoland/deno/discussions or https://discord.gg/deno.

[jsejcksn]

Is anything here actionable for us? If not I would like to close and move the discussion to https://github.com/denoland/deno/discussions or https://discord.gg/deno.

I'm ok with that. Please post here the link to the new discussion if you move it.

[Higgs1]

Hello,

I/we would very much like to write Web-compatible modules in TypeScript (that only utilize Web compatible APIs) to JavaScript so that it works in Web browsers and/or other runtimes that can run ES2015 compatible JavaScript. Has there been any progress on this? I/we are fine with any build pipeline that does this, as long as it doesn't involve sentient beings changing ".ts" to ".js" (this is what computer software is for).

[jsejcksn]

@Higgs1 I infer that you also don't necessarily want to bundle, leaving that concern to a downstream handler. Here's an example based on what @ayame113 commented:

import { a } from "./mod.ts";
import { b } from "./mod.js";
import { c } from "./mod.ts.js";

console.log({ a, b, c });

In that case, what should be the output in accordance with your imagined specifier rewriting system?

Further (Socratic): Have you thought through conflict cases and considered a ruleset which can handle all such cases?

[Higgs1]

Hi @jsejcksn ,

With the input from several others, I'm pretty confident that I've thought through a wide variety of cases: I don't want any particular specifier rewriting system - not yet anyway, others may standardize a convention later if they want. As you've mentioned elsewhere, the code that's written should follow the conventions of the compiler. Right now, the only puzzle piece I'm interested in is a hypothetical transpiler that emits valid, working JavaScript that conforms to WHATWG's module loading system in a deterministic way. Here are a few possible rewriting systems that I've come up with:

1. Output to a different path, don't rewrite any specifiers.

import { a } from "./mod.ts";
import { b } from "./mod.js";
import { c } from "./mod.ts.js";

console.log({ a, b, c });

2. Hash all specifiers. Note: Produces collisions.

import { a } from "./e6eb0057c923c4a224c4d05275cf35cf";
import { b } from "./74c68ff4eff48c7f153caba19b3307cb";
import { c } from "./844aa07b6e487967e3f135148baa9126";

console.log({ a, b, c });

3. Just append .js to everything. Guarenteed to be unique. Causes issues on systems where path length is limited.

import { a } from "./mod.ts.js";
import { b } from "./mod.js.js";
import { c } from "./mod.ts.js.js";

console.log({ a, b, c });

Rewriting external imports seems to be a completely tangental yet equally possible problem. One can probably utilize annotations on the remote side (like @ sourceMappingURL - "hey, my transpiled ESM code is at..."), an HTTP header if served over HTTP (like X-TypeScript-Types), annotations when importing (like @deno-types - "the ESM code for this TS resource is at..."), specifying them in a sort of input mapping file, specifiying a specific pre-defined ruleset (by command argument for example), or if all else fails just pull them and compile them locally alongside the original codebase; or a combination of all the above.

[jsejcksn]

@Higgs1 Based on your interest in this, I also want to make sure you're aware of a proposal which relates to some of the concerns you've shared: ECMAScript proposal: Type Annotations

[Higgs1]

Oh thank you @jsejcksn , I was not aware of that proposal but that's something I've been looking for since 2012. Like JSDoc, but defined as part of the syntax. We can finally get rid of TypeScript. Unfortunately I have absolutely no idea how to contribute to that. I had started a discussion about types in JS on webplatform.org earlier (/ a decade ago) but it didn't go anywhere... I've increased the project's star count at least.

Additionally, a note on our progress: we're working on coercing esbuild to do what we want, using a separate output directory (method no. 1 above). There's a lot of steps that aren't obvious because we want a .d.ts file, and a minified file, and we need to process the intermediate source mappings.

Apparently Microsoft decrees that JavaScript files use the .ts extension now (and thus far we're obeying!). It's still pretty madenning that the JS community is so close, yet so far way...

[Higgs1]

Update: any setup that involves leaving the files as .ts extension makes practically every service serve the files as either text/plain or video/mp2t which is incorrect. Changing the content type is not possible on any of these hosting services.

We're at a complete loss. What can be done? Should I post something on the Type Annotations proposal issue tracker? Why is the community so intent on starting a new browser war?

[ondras]

Hi,

FYI: tsc now accepts .ts imports, so this issue/discussion is no longer relevant - at least in my original case.

[nayeemrmn]

Out of curiosity, what tool are you using to build that TS for the browser?

[ondras]

esbuild seems to bundle that. Not sure what minimum version would work - 0.17.18 is the one I successfully tried.

[ondras]

(my main problem with .ts imports was VS Code, though - which now works with the "allowImportingTsExtensions": true option)