Suggestion: importing internal modules with ES6 syntax

[boris-kolar]

It would be nice to import internal modules with ES6 syntax. Example:
you could write...

import "Lib/Utils" // new syntax (maybe import "Lib/Utils.ts" should work too?)

... instead of the old way

/// <reference path="Lib/Utils.ts"/> // old syntax

[mhegazy]

These two do not mean the same thing.

import "Lib/Utils" 

is an ES6 module import that is already supported in TypeScript 1.5. and as per the ES6 module semantics, it turns your file into an external module that has a dependency on another module Lib/Utils. by turning it into an external module it implies that you have a module system that will load your dependencies, be that AMD (requirejs for instance) CommonJS (if you are writing a node app), or ES6 modules (if you are on an ES6-enabled engine that supports modules).

On the other hand:

/// <reference path="Lib/Utils.ts"/> 

Is a TypeScript compiler directive to help the compiler figure out the context without specific all files on the command line. the file is not considered an external module, and there are no run time dependencies added.

I do not think we want to overload the ES6 import "mod" syntax for this purpose, as 1. it is ambiguous, and 2. it really means a different thing.

[RyanCavanaugh]

A patch would not be accepted. We don't want the language to have confusing constructs in it, or more ways to import/export than we already have (which is too many to begin with).

[boris-kolar]

After thinking a little bit more about it, I don't think supporting ES6 for importing internal modules would be confusing at all. Even now, the import syntax can have different meanings (it could mean importing CommonJS modules, or importing AMD modules, or importing ES6 modules).

So we have 2 scenarios (assuming Foo.ts includes ES6 import directive):

1. tsc -t ES5 --out Foo.js Foo.ts
   Now: error TS1148, Proposed: interpret import as /// <reference path=...
2. tsc -t ES6 --out Foo.js Foo.ts
   Now: generates wrong code (!!!), Proposed: interpret import as /// <reference path=...

So, why not? Internal modules can be seen as just another module system. If there's still any confusion, then perhaps adding a new module flag (eg. "-m internal") would solve the issue? The "///<reference" syntax is far worse.

[danquirk]

@jbondc The current ways to use modules are absolutely confusing. However, it is not the case that doing different things the same way automatically reduces confusion. It can actually create more confusion when seemingly identical things now have different (either subtly different or very different) behavior.

As a concrete example, consider internal vs external modules today. They're sort of similar so they were both called modules. You use the module keyword with each. But it turns out that actually creates more confusion than naming them discretely and so we're currently considering using 'namespace' going forward rather than 'internal module.'

[mhegazy]

We have to keep supporting /// references for the foreseeable future. same for import = require, and the new import syntax. this adds yet another variant.

[danquirk]

Of course module vs namespace is a different issue. The point was merely to illustrate how an apparent reduction in complexity (1 keyword instead of 2) can actually be the opposite. In addition, as Mohamed notes in the near term you automatically add complexity as long as you're continuing to support the old solution (which we must) so the value of the simplification must be significant.

We have already gotten feedback that many people don't like the behavior where you cannot read an import statement and know whether it causes an import to be emitted (ie whether code is loaded). It's a situation we are trying to improve. Unifying import around internal and external modules would only exacerbate this issue. Now you would have 1 import syntax but exactly how it is imported is unclear from simply reading the code. So you have traded one sort of complexity/confusion for another.

[mhegazy]

Personally, I think the correct way to solve this is to have a clean and complete module story, so you do not need to /// reference your way out of problems.
Part of it is a better module resolution, and a better way to expose and include typing files (e.g. #2338), another part is an easy way to turn your modularized code into a script that can be included in webpage possibly without a loader,e.g. umd support #2036, and bundling #2568 and #2743

[M-jerez]

-1
Module systems and interoperability is becoming a nightmare in Typescript and there is not even updated documentation about it. If I could suggest something is to remove all module system and leave only internal modules and ES6, for the goodness of Typescript ecosystem.
You are on time now that Typescript is still not massive

[mhegazy]

and there is not even updated documentation about it.

@M-jerez can you take a look at handbook at: https://github.com/Microsoft/TypeScript-Handbook/blob/master/pages/Namespaces%20and%20Modules.md, and let us know what topics need more coverage?

[M-jerez]

can you take a look at handbook at: ...

@mhegazy this is actually a very good documentation it would be great to have a link to it from the official website http://www.typescriptlang.org/Handbook#modules.

I just couldn't find it before (it is appearing in google search now), thanks for pointing it.

[ghost]

+1 on simplifying the internal module usage syntax.
One must admit that the /// syntax is ugly at best. Besides, turning comments into meaningful compiler directives - what year is this? the whole mantra of the language was to be simple and empowering - and from the start, that syntax was like a big facepalm for simplicity and readability.
JS already has the string-form directives "use strict", "use asm", etc. Why not something like this? e.g.: "use ./whatever-the-internal-module-path"; (note the "./" prefix).
There must be a better way, I'm sure of it. It just requires more will.