Why these import/export statements behave differently...?

[iam3yal]

Why these import/export statements behave differently? I mean I understand they were originated in two different specs but should they behave differently?

What bothers me is that when I'm using the ES6 style to import the class I need to access it through another scope (module/namespace), is there a way to avoid it? or should I just use CommonJS modules style?

It was probably fine if I could import many classes/modules to the same scope.

// a1.ts
export class A {
}

// b1.ts
import * as A from "./a1.ts";

class B extends A.A {
}

Just another variation with modules.

// a1.ts
export module C {
    export class A {
    }
}

// b1.ts
import * as D from "./a1.ts";

export module C {
    class B extends D.C.A {
    }
}

Versus the following statement:

// a2.ts
class A {
}

export = A;

// b2.ts
import A = require("./a2");

class B extends A {
}

I'm not sure what the following does but it compiles, is it a bug?

// a3.ts
class A {
}

export = A;

// b3.ts
import * as A from "";

class B extends A {
}

[basarat]

Just another variation with modules.

module has been renamed to namespace http://basarat.gitbooks.io/typescript/content/docs/project/namespaces.html

Don't use them with es6 / commonjs / amd / system modules as they are not needed.

---

Versus the following statement

Don't use export =. It was common in AMD / CommonJS land but not recommended since ES6 has landed. In fact its not even supported with ES6 (barring some hacks ... that if I mention will only confuse).

---

I'm not sure what the following does but it compiles, is it a bug?

Looks like a bug. Are you sure there are no errors?

[iam3yal]

Thanks for answering.

Don't use them with es6 / commonjs / amd / system modules as they are not needed.

I haven't used namespaces so far but why they aren't needed?

Don't use export =. It was common in AMD / CommonJS land but not recommended since ES6 has landed. In fact its not even supported with ES6 (barring some hacks ... that if I mention will only confuse).

Okay I won't use it but why there's differences in behaviour? why do I need to go through additional scope to access the class/module? whereas in CommonJS style I don't.

I'm not using ES6, I'm compiling to ES5.

Looks like a bug. Are you sure there are no errors?

I'm pretty sure I'm not getting errors! it's compiling.

Here is the tsconfig.json file I'm using for this project.

{
    "compilerOptions": {
        "noImplicitAny": false,
        "noEmitOnError": true,
        "removeComments": false,
        "inlineSourceMap": true,
        "experimentalDecorators": true,
        "target": "es5",
        "module": "commonjs",
        "outDir": "./.out"
    }
}

[basarat]

I haven't used namespaces so far

namespace is same as (now deprecated) module (used here export module C {).

but why they aren't needed?

Because if you have a root level export or import in your file ... your file gets a local scope. You are no longer polluting the global namespace and hence your file is already a module. You don't need to needlessly nest stuff inside again by using namespace.

Okay I won't use it but why there's differences in behaviour? why do I need to go through additional scope to access the class/module? whereas in CommonJS style I don't.

Not a choice made by TypeScript. Rather by the ES6 committee. Its for static analysis : http://www.2ality.com/2014/09/es6-modules-final.html Note that it does not reflect opinions of the TypeScript team ... rather the ECMAScript committee.

I'm pretty sure I'm not getting errors! it's compiling.

Yup. Bug reported : #4772

[iam3yal]

Not a choice made by TypeScript. Rather by the ES6 committee. Its for static analysis : http://www.2ality.com/2014/09/es6-modules-final.html Note that it does not reflect opinions of the TypeScript team ... rather the ECMAScript committee.

The rational is quite odd here because when you have multiple functions in a single file then there's no doubt that it's reasonable to create a scope to contain all the functions in the file as if the file itself was somewhat a class

However, when it comes down to classes it's very different, people don't tend to put many classes in a single file like you would with functions and in fact there's a consensus to have one class per file and many guidelines for many programming languages follow this tenet.

Again, like I said if it was possible to import many files into the same scope then it was working fine because then we could split related classes into different files like we would normally do in other languages which would solve this problem.

I guess I need to create a different post/proposal for this feature though but I'm not sure how to structure my project now, any ideas what's the best way to approach this?

[basarat]

any ideas what's the best way to approach this?

NPM / commonjs / Webpack all things .... at least that's my moto 👍 🌹

[iam3yal]

haha.. ;)

Never mind! I read things more thoroughly and I found exactly what I was looking for!

import {A} from "./a1.ts";

class B extends A {
}

[basarat]

I read things more thoroughly and I found exactly what I was looking for!

Yup. That is my preferred syntax even when targeting commonjs/NPM.