Support `compileOnSave` for `--out`

[basarat]

I don't use --out. So up for grabs.

I don't recommend --out because : https://github.com/TypeStrong/atom-typescript/blob/master/docs/out.md

[basarat]

From @erikvullings : 1380a83#commitcomment-10394359

---

I've promised you an example of my project that uses the -out feature and
which has several issues:

• it cannot use incremental builds (actually, it builds something, but
  when I use the resulting js file, it complains that __extends is not
  defined). I have to do a full build.
• *since version 1.8.0 of atom-typescript my project doesn't compile at
  all: *although the building message is generated, an error is generated
  in the console (promise is rejected) and no output is generated. I've
  copied the stack trace below. Please unzip the attached file and see for
  yourself.

The attached project should generate a csComp.js file in the dist folder.
This is loaded in the csMap https://github.com/TNOCS/csMapclient
application to create an Angular SPA map. If you need the front end too,
let me know, and I'll send you a copy too.

Hope this helps.

Cheers,
Erik

"TypeError: Cannot read property 'file' of undefined↵
at
C:\Users\vullingshjlm\.atom\packages\atom-typescript\dist\main\lang\modules\building.js:31:24↵

at Array.forEach (native)↵
at Object.emitFile
(C:\Users\vullingshjlm\.atom\packages\atom-typescript\dist\main\lang\modules\building.js:30:20)↵

at
C:\Users\vullingshjlm\.atom\packages\atom-typescript\dist\main\lang\projectService.js:233:31↵

at Array.map (native)↵
at Object.build
(C:\Users\vullingshjlm\.atom\packages\atom-typescript\dist\main\lang\projectService.js:232:50)↵

at Child.RequesterResponder.processRequest
(C:\Users\vullingshjlm\.atom\packages\atom-typescript\dist\worker\lib\workerLib.js:38:60)↵

at process.<anonymous>
(C:\Users\vullingshjlm\.atom\packages\atom-typescript\dist\worker\lib\workerLib.js:214:23)↵

at process.emit (events.js:119:17)↵
at handleMessage (child_process.js:326:10)"__proto__:
Object__defineGetter__: function __defineGetter__() { [native code]
}__defineSetter__: function __defineSetter__() { [native code]
}__lookupGetter__: function __lookupGetter__() { [native code]
}__lookupSetter__: function __lookupSetter__() { [native code]
}constructor: function Object() { [native code] }hasOwnProperty: function
hasOwnProperty() { [native code] }isPrototypeOf: function isPrototypeOf() {
[native code] }propertyIsEnumerable: function propertyIsEnumerable() {
[native code] }toLocaleString: function toLocaleString() { [native code]
}toString: function toString() { [native code] }valueOf: function valueOf()
{ [native code] }get __proto__: function __proto__() { [native code] }set
__proto__: function __proto__() { [native code] }

[basarat]

I don't recommend --out because : https://github.com/TypeStrong/atom-typescript/blob/master/docs/out.md

[kungfusheep]

Hello

First of all - Atom Typescript is fantastic, we've been looking into it as a cross platform alternative to visual studio.

On the subject of --out, we have a rapidly growing codebase, currently of around 300+ .ts files over a few different projects/libraries, which relies on the use of --out and the generation of sourcemaps by the typescript compiler.

I'm not sure removing support for it becuase it doesn't fit your personal use-case is the right thing to do. Namespaces suit our codebase, we don't want to use an external module loader and are quite happy with the level of control we get from ordering the combination from _references.ts.
Changing the codebase as it is now to use a different scheme for loading & referencing modules all use ATS just isn't feasible.

Do you think the decision to remove support for --out could be reverted given that the TypeScript compiler itself supports it?

Cheers
Pete

[basarat]

Thanks for the kind words 🌹 Note that I use --out elsewhere too : https://github.com/basarat/typescript-collections but wouldn't do it again.

I'm not sure removing support for it becuase it doesn't fit your personal use-case is the right thing to do

Agreed. That is why this issue is open for grabs ;)

namespaces suit our codebase, we don't want to use an external module loader and are quite happy with the level of control we get from ordering the combination from _references.ts

The TypeScript team doesn't support _references for tsconfig : you'll have to use files and it is going to get messy : microsoft/TypeScript#2472 (comment)

Changing the codebase as it is now to use a different scheme for loading & referencing modules all use ATS just isn't feasible

Please reconsider. I've spent a weekend at work at one point. Not saying you should spend a weekend but consider it a part of a future migration.

Do you think the decision to remove support for --out could be reverted given that the TypeScript compiler itself supports it

I am not removing it. Just warning that we don't have good support for it yet. The editor will work fine otherwise.

[csnover]

I feel compelled to second @basarat here, for your own sake. 300+ and growing files with all manual dependency management is a house of cards just waiting to collapse. Take a couple days to fix it now for your own sake. :)

[kungfusheep]

@basarat Thanks for the reply.

I am not removing it. Just warning that we don't have good support for it yet. The editor will work fine otherwise.

This seems to be contrary to what I'm experiencing. See the screenshot below - it's an error that is generated, not a warning. The build no longer runs as it did in previous versions.

@csnover With all respect, it's difficult for you to pass judgement on the best approach for our software development without knowing what kind of company we are, what the software does and the methodologies we employ in-house. Having dependency loading managed by our own code gives us greater control over a large development team.

Cheers.

[Deathspike]

@basarat @csnover I'm confused why you both would call --out such a bad idea.

• Runtime errors; Applications should wait for an equivalent of ready before bootstrapping.
• Fast compile; You can compile single files into temp and emit a combined file. VS13 is fast.
• Global Scope; Choosing --out means choosing for a var on window. It's not bad; it's a choice.
• Hard to analyze; I don't get this at all. Hampering a pipeline for the sake of easier tooling dev? 👎
• Hard to scale; Still no problem with a huge amount of files and VS. TS1.4 seems fast enough.
• _references.ts; Is unnecessary if you choose for the ready-approach mentioned earlier.

I prefer the --out method as well, for front-end applications (especially Angular ones). Having to import every single interface and other kind of reference is extremely cumbersome. I just type in the name (ala C#) and expect it to be in my application scope (or say, I do a import Shared = App.Shared for a using or namespace if you will). There is no good reason to discourage it just because it doesn't fit your preference of front-end tools.

[nycdotnet]

I must say I prefer internal modules as well, though I prefer bundling on the back end in a build script rather than with --out.

Bundling on the Back End is the name of my next heavy metal album.