tsickle only has a devDependency on google-closure-compiler, but the binary depends on it

[jjudd]

As the title mentions, google-closure-compiler is in the devDependencies section of package.json. However, the binary supplied by main.ts requires google-closure-compiler. As a result, unless you have google-closure-compiler installed, tsickle fails to run.

For example:

Error: Cannot find module 'google-closure-compiler'

To resolve this, google-closure-compiler should probably move to peerDependencies or dependencies. Alternatively, the cli could be split into its own module, as suggested in #137.

Thoughts?

[evmar]

(Are you working on an Angular2 app, by chance? As mentioned in #137, for Angular2 it's likely they'll have their own tsickle wrapper etc., which is why we haven't put much work into the tsickle command line.)

For now we can fix this by moving the dependency into a non devdependency. @alexeagle will this break your ngc stuff?

Otherwise, I am kinda new to nodejs packaging stuff -- if you have suggestions on how to best set up a separate CLI package (ideally it'd still be in this repository) I'd welcome it.

[alexeagle]

If we make it a dependency then all angular 2 users will download closure compiler, which we don't want.
I think you need the @angular/tsc-wrapped package to support closure-annotating the output. I did an experiment with it alexeagle/angular@2d1c21f which I think we need to get into the main repo.

[jjudd]

Hi @martine. I'm working on Lucidchart, which has Angular2 parts and plain on JavaScript parts. All of it is run through the closure compiler. I'm interested in getting TypeScript to work with the entire codebase, so I'm trying out tsickle and clutz.

I was planning on the workflow being .ts -> (tsickled .js) + (regular closure .js) -> closure compiler. Our build system should be able to handle everything once I run it through tsickle. The command line tool seemed like a great way to make that happen. Just run it with saveTemporaries and then send those with the rest of the js into the closure compiler.

With what we plan on doing, it is more useful for to have the CLI not do closure compilation. Instead it would just annotate the js and output the files. That would also solve the dependency problem on the closure compiler, but I'm not sure if it is in line with the goal of the CLI tool.

[evmar]

That seems reasonable to me! As far as I know you are the first person to try this, so perhaps we should just delete the calls to the closure compiler entirely from main.ts and instead say tsickle only does the .ts->.js translation.

That is, delete the code around here:
https://github.com/angular/tsickle/blob/master/src/main.ts#L284

The reason I didn't do this originally is that there's a whole bunch of tsc functionality (like --outDir) that I didn't want to fiddle around with. When tsickle internally handles all of the ts->js->closure then we don't have to worry about paths. So if tsickle instead outputs .js I think we need to figure out what responsibility/flags/behavior tsickle has for choosing the output path.

(The even easier thing would be for tsickle to just do .ts->.ts translation and leave the rest to you. But in that case, we would also need to output to a different directory, because the output filename has to be the same as the input filename.)

[jjudd]

I'm a fan of deleting the calls to the closure compiler. As to whether tsickle should do ts -> ts or ts -> js, either works.

If tsickle only translates from ts -> ts, then users will manually have to add the CommonJS to Google Modules translation which happens here:
https://github.com/angular/tsickle/blob/master/src/main.ts#L218

However, that allows quite a bit of flexibility in terms of the build process. I'll play around with things as I get tsickle into our build process. I imagine I'll have far more insight at the end of that than now :)