Module Syntax

[matthiasg]

I had assumed that the module syntax as described in (https://github.com/Microsoft/TypeScript/wiki/Modules) was a remnant of earlier times when es6 wasnt clear on that topic yet and that the old module syntax usage was not encouraged anymore since its already solved in es6.

Since Modules as described there shouldnt be necessary for the benefits of TypeScript, shouldnt it be marked as deprecated or at least somehow tagged as backwards compatible only ?

PS: What are the plans on deprecating features in the future as ES catches up anyway ? Will the compiler emit warnings or notes or whatnot ?

[RyanCavanaugh]

"internal" modules, as they were called, can now be written with the namespace keyword instead for clarity. They remain useful as a scoping construct and will not be deprecated.

I don't see us deprecating import x = require('foo');. It's too widely used at this point and is very clear in its intent. Teams can opt in to a linter or whatnot if they want to enforce certain conventions like only using ES6-style imports.

[matthiasg]

Great idea about the linter. Does anybody know of a linter that supports es6,es7 and typescript. E.g doesn't fail when using types and only allows es6/7 ?

-----Original Message-----
From: "Ryan Cavanaugh" notifications@github.com
Sent: ‎17.‎07.‎2015 19:25
To: "Microsoft/TypeScript" TypeScript@noreply.github.com
Cc: "matthiasg" mgt576@gmail.com
Subject: Re: [TypeScript] Module Syntax (#3908)

"internal" modules, as they were called, can now be written with the namespace keyword instead for clarity. They remain useful as a scoping construct and will not be deprecated.
I don't see us deprecating import x = require('foo');. It's too widely used at this point and is very clear in its intent. Teams can opt in to a linter or whatnot if they want to enforce certain conventions like only using ES6-style imports.
—
Reply to this email directly or view it on GitHub.

[DanielRosenwasser]

tslint has no-require-imports but that's as far as it goes from what I can see.

[matthiasg]

@RyanCavanaugh I see you closed the issue referencing a linter. Could you point me towards one that solves this? I am genuinely curious because I had investigated that a few months ago and could find anything.

[ashwinr]

@matthiasg please file an issue on us at github.com/palantir/tslint // CC @adidahiya

[RyanCavanaugh]

I don't know that a linter already exists for that specific use case, but tslint will probably take a PR if there's a rule that makes sense.

[matthiasg]

@ashwinr ok I will specify more clearly next week and file an issue..

@RyanCavanaugh I think a process to keep Ts code as standards compliant as possible will be quite helpful to the number of teams coming to typescript in order to use angular 2 most effectively. Right now we are using babeljs because it's a direct fit with no changes required to an existing project whereas we couldn't get TS to work.

[RyanCavanaugh]

Can you expand on what blocked you? I assume that us not warning on old syntax was not the problem 😉

[matthiasg]

There was no way to use Ts as a drop in replacement. I had thought every valid js file is a valid Ts file as e.g es6 is to es5 , but that wasn't the case for us.

We have a gulp, browserify, angular setup.

Adding e.g Babel was straightforward, just add babelify and we could use es6 features mixed with the existent requires and still use e.g import , thus allowing for a simple migration. With TS there were numerous issues.

E.g require had to be defined (meaning adding a declaration line to every file)

Import not finding modules ( e.g import app from '../application' as a replacement for var app = require('../application')

Ts compiler removing imports when they weren't used ( which is quite helpful since it's required/helpful for DI systems e.g angular1)

Even with that working sometimes the generated bundle contained no content but due to ask the other issues we stopped investigating that.

[adidahiya]

@matthiasg I've been able to use TS with external modules & webpack with no issues.

for the issue of needing to declare require in every file, you could set up a project with tsconfig.json and include some "references" file that declares require in the project before your source files.

Import not finding modules ( e.g import app from '../application' as a replacement for var app = require('../application')

could you elaborate here?

EDIT: that replacement won't work unless ../application has a default export. you could try import * as app from '../application'

tslint:

The no-require-imports rule should help you, but note that you still need to require() commonjs modules (all your third-party libs).

If you also want to ban internal modules ("namespaces"), I'd gladly look at a PR for a new linter rule.

[matthiasg]

@adidahiya application.js would be a normal common js file with module.exports = ...

the idea is to introduce typescript in a slow and orderly fashion and not change every file bottom up to be touched.

for namespaces: having looked at that i would have to do some experimentation with it to find out how this would really affect us since it seems to map very well to a simple wrapper function ...(){}. in case we find it bothersome i might follow up with a PR...

BTW tslint should be mentioned much more prominently in the TS docs, i myself missed that.

[adidahiya]

@matthiasg a PR for a no-internal-module rule in tslint is underway: palantir/tslint#517