TypeScript and <script type="module"></script>

[cyrilletuzi]

A first implementation of <script type="module"><script> just landed in Safari Technology Preview 21, so I tried to use it on a TypeScript / Angular project, to finally get rid of system.js.

First issue, resolved but unconvenient : ES6 modules paths must include the '.js' extension. Fortunately, TS 2.0+ knows how to resolve import { Something } from './test.js' into import { Something } from './test.ts' while in dev. But it's a huge change to common practices and a lot of refactoring : official TypeScript docs, Angular, RxJS and so on have all encouraged until know to use the no extension form (import { Something } from './test').

Second issue, unresolved : TS provides many options to tell the compiler how to resolve paths like import { Component } from '@angular/core'. But it never transforms the imported path in the compiled files. '@angular/core' will stay '@angular/core' in the transpiled files. After investigation, I've read in many issues it is by design.

It's OK with loaders like system.js and others, which provide similar path mapping options. But with <script type="module"><script>, as far as I know, there is no configuration, so import { Component } from '@angular/core' will always fail.

I am missing something, or does that really mean that we won't be able to use the native loader with TypeScript projects ?

If I'm right, is it possible to add an option to force path transformation in compiled files ?

[aluanhaddad]

Just a comment. It seems ironic that you wish to

to finally get rid of system.js

When it is about the only option comes that close to what you seem to be trying to achieve.

But it's a huge change to common practices and a lot of refactoring : official TypeScript docs, Angular, RxJS and so on have all encouraged until know to use the no extension form (import { Something } from './test').

Personally, I think extensionless imports are far better, they make your code far more portable.

I suspect the native loader will eventually support configuration. Of course the specification is in major flux, but there is likely to be a configurable API to perform abstracted name resolution for imports like

import {Component} from '@angular/core';

because it is clearly needed and because the issue has been discussed at least to some extent. I've heard discussion of how to resolve

import $ from 'jquery';

You may find this repository interesting https://github.com/whatwg/loader/

If I'm right, is it possible to add an option to force path transformation in compiled files ?

No this is not possible at present.

[cyrilletuzi]

I don't see what's ironic in wanting to depend on native and standard features, instead of librairies...

[aluanhaddad]

Sorry I am a dyed in the wool SystemJS user (actually I'm not sorry 😜). But the whole point of SystemJS is to get out of the way, when native loaders are available, but until then polyfill the loader specification (and provide other features such as CommonJS interop).
In other words it has built in obsolescence, by design, so it does not interfere with the future it seeks to enable today.

Seriously SystemJS is great. Not every framework uses it well, for example Angular 2, made poor use of it and is now removing it. Look at Aurelia as an example framework that, while not requiring SystemJS, uses it by default and plays to its strengths showing how elegant it can be.

[cyrilletuzi]

It's not a charge against SystemJS. Yes, it is a nice tool. But as you said it very well, it was designed as a temporary tool until the native loader is finally here.

So now the central part of it is there (<script type="module"></script>), but unusable in a real case : I can't see the point if we can just load a few local scripts, and no librairies. So I'm confused.

Hopefully configuration is coming. Or hopefully TypeScript will manage it.

[aluanhaddad]

Check this out. https://github.com/guybedford/isomorphic-browser-modules

[Avol-V]

Personally, I think extensionless imports are far better, they make your code far more portable.

SystemJS didn't recommend to use default extension as well.

[mhegazy]

i am not sure I see why this is a TS issue. If you put the full file path in the module, it should work. Or putting it diffrentelly, how could you do the same with a plain .js file with the typescript compiler completely out of the picture?

[Avol-V]

Whether TypeScript transforms paths or not, it could be an option to add extension to the names of modules (or it could convert .ts to .js).

[mhegazy]

import .. from "./foo.ts" is not allowed so it is either "./foo.js" or just "./foo". I would recommend using consistent extension and always specify .js.

[cyrilletuzi]

i am not sure I see why this is a TS issue. If you put the full file path in the module, it should work

As far as I know, TypeScript doesn't support absolute paths. So no, it doesn't work.

After a deeper thinking, I think the current behavior is really not normal. As a transpiler, TS should produce standard and ready-to-work JavaScript. TS also choose the very good design option to be "just" enhanced JS, ie. backward compatible with normal JS.

import { Something } from './something' is clearly not standard JS.

[mhegazy]

As far as I know, TypeScript doesn't support absolute paths. So no, it doesn't work.

what do you mean absolute path? can you share an example of an app with a module that is absolute? a CDN path should work with a path mapping entry.

import { Something } from './something' is clearly not standard JS.

We do not know what node will do yet. but if node considers this invalid filename, the compiler can flag it as an error. either ways, you should just write:

import { Something } from './something.js'

[cyrilletuzi]

We do not know what node will do yet. but if node considers this invalid filename

It's already an invalid filename for browsers, which is the main use case of TypeScript.

you should just write: import { Something } from './something.js'

I agree, that's what I do now to be future proof. Problem is, like I said on first message, that it's a huge change to common practices and a lot of refactoring : official TypeScript docs, Angular, RxJS and so on have all encouraged until know to use the no extension form (import { Something } from './test').

For absolute paths, I mean a code like this :

import { Component } from '/node_modules/@angular/core/index.js';

Otherwise, I need to do things like this :

import { Component } from '../../../node_modules/@angular/core/index.js';

First, it's a mess, second, it doesn't work if outDir is not at the same path level.

[cyrilletuzi]

you should just write: import { Something } from './something.js'

And most importantly, I can refactor my code, but I can't refactor librairies I use...

[mhegazy]

It's already an invalid filename for browsers, which is the main use case of TypeScript.

No it is not if you are using requireJS, Browserify, Webpack, SystemJs, etc.. i.e. any thing other than a browser that supports native ES6 modules, and as i far as i know, there are not many of these around today.

[mhegazy]

For absolute paths, I mean a code like this :

The loader spec does not really talk about how these absolute paths are allowed. When we have a clear description of that, allowing such should not be hard.