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.

[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.

[nayeemrmn]

At least the interop between Deno and tsc is discussed in #3196. We basically need microsoft/TypeScript#33437. I'm here #3196 (comment).

[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.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jsejcksn]

Not stale

[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.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.