How does cross-compiling with TypeScript work when tsc has to have every file in the project to compile a file? (i.e. TypeScript by-design isn't a simple 1:1 mapping unlike Babel or CoffeeScript, to compile input file X, you need the type definitions of all the types it uses including the other files in the project).

cross-compiling with TypeScript work when tsc has to have every file in the project

Not essentially. Consider

foo.ts

var foo = 123; 
export = foo;

bar.ts

import foo = require('./foo');
console.log(foo); // 123 

Each file can be compiled on its own. However file bar in the absence of type information of foo despite being syntactically valid, is semantically invalid. It would be semantically valid only if it had reliable information about foo.ts. However the TypeScript compiler doesn't block JS emit in the presence of semantic errors.

I have semantic validation disabled by passing false here : https://github.com/atom/atom/pull/5898/files#diff-1bb8c8dc24534560f9903363ebb9a332R97

Also, call sites in TypeScript do not rely on source type information. So absence of type information does not change the emit. This is by design.

@paulcbetts I've just pushed a multifile demo : basarat/atom-typescript-test@1dfe56b

The files are compiled separately (in the absence of type information about the other files) and still work :

@basarat Aha, now it makes sense. It'd be cool to start making a more generalized framework for loading cross-compilers, because they're going to start hurting startup time and require perf (and hurting require perf is pretty bad, though in the TypeScript case it's a very quick "Does file end in .ts" check)

hurting require perf is pretty bad

In general hurting require perf even a little is gonna run counter to this goal (and the 1.0 goal of reducing startup time) in a big way and will need the most convincing of justifications: electron/electron#169

@thedaniel I think this can probably be pretty easily done, since these require hooks are so easy to register. We just put it off until we find typescript files

👍 https://discuss.atom.io/t/how-to-use-the-npmignore/9208/6
https://github.com/vvakame/language-review/tree/master/lib I want to ignore compiled .js code.

Also I couldn't get sourcemaps to work because of fancy JS wrapping : TypeStrong/atom-typescript#156 (comment)

Note: I can get them to work with more custom code but I'd rather atom do it for me + any other TS package authors.

@basarat So is this something that is ready to review? Or did you still have any planned changes left?

Could you add some tests for this as well? You can model them after the babel specs.

@kevinsawicki was ready for review. I'll add the tests tonight and ping you.

@kevinsawicki ready for review. Also updated (and marked as completed) the todo list ❤️

@kevinsawicki ready for review again. Did:

• didn't need jasmine.snapshotDeprecations() so removed
• The js file was there as a PR was pending. Since been merged so depending on the library typescript-simple directly. So js file removed.
• ran script/grunt lint zero errors.

Also I'm now using JSON.stringify. Don't see why that wasn't used for babel.

@kevinsawicki done:

• remove typescript dependency as it is not required explicitly

Thanks for making all these updates, this feels like it is getting really close.

One thing I thought of though was this should be added to the compile-cache helper class that is called directly by apm:

And also to

compile-cache is called directly by apm when apm install is run so that the cache is populated before the package is loaded in Atom so installed packages don't slow down startup when they are first installed.

@kevinsawicki done:

• add TypeScript to the compile-cache + compile-cache-spec

Thanks @basarat, this looks really nice.

Just chiming in, as @basarat mentioned TypeScript errors do not block the generation of JavaScript. we have always thought of the type check errors as warnings that the compiler provides the developer at design time but do not block the rest of the tool chain.

In general TypeScript does not have emit that depends on global program optimizations, we have steered away from these for the most part. So in Atom's context it should be safe to use typescript as a single file transpiler without loosing correctness. For completeness sake, there are
two places where the compiler relies on the full program information to direct emit, 1. TypeScript internal modules (this is not relevant in atom's case everything is treated as node modules) and 2. use of const enums from .d.ts files (for this i have created an issue to ensure that there is an API interface that handles these correctly).

We would like to also add new API for single file transpilation, making typescript-simple's life much simpler (no pun intended :)); and to ensure this scenario is well supported in the future.

It is really nice to see TypeScript plugins in Atom. can not wait to try writing one myself!

Awesome, thanks so much for adding this 🚢

❤️ can't thank you enough for this.

We would like to also add new API for single file transpilation, making typescript-simple's life much simpler (no pun intended :)); and to ensure this scenario is well supported in the future.

Awesome! I'm waiting.