Inconsistent import behavior would cause `.d.ts` to break.

TL;DR;

The current inconsistent import behavior in different module mode (system or commonjs) would cause .d.ts to break (1.8 included).

Potential Solution

• Add a "module {system,commonjs}" directive and so that the .d.ts file will be processed correctly
• Unify the import/export syntax and behavior
• .d.ts uses a module agnostic import/export syntax

Context

The context of this problem is about module mapping (such as what jspm and typings supports).

Basically saying any module can be referenced by a different name to avoid module name collision. e.g. in a project that use two versions of jquery, one would be imported normally (import $ from 'jquery'), one would be imported with a different name (import $old from 'jquery@1.6').

In 1.8, with the support of allowSyntheticDefaultImports enables the behavior become similar (but if the user set it to false could still diverge). However the behavior of import * as A from 'abc'; and import dr = require('domready'); are still different.

Problem

The current (1.8) module support is working fine when creating package in TypeScript and distributing it as .js.

However it does not work if the package is distributed in .ts or with .d.ts.

The reason is that when distributing in the compiled form, the module mode used by the package author is captured in the .js file. When distributing .ts and .d.ts it relies on the consumer to use the same module mode as the package author intended.

This means if the package authors (including all typings authors) create the package using one module mode, and the consuming application/package use a different module mode, the system will fail.

It is worse if the consuming application/package uses multiple packages with disagreeing module mode.

Here are the original discussion:
https://github.com/typings/typings/issues/149

This is closely related to:
https://github.com/Microsoft/TypeScript/issues/7125

Please let me know if there are any confusion or missing information / context.

The issue names no files, entry points, or tests. Start by reading the linked typings/typings#149 and TypeScript#7125 discussions, then compare the reported system and commonjs import behavior. Done means an agreed, tested design for module-agnostic .d.ts imports and exports.