Extract features from grunt-ts to own modules

[Bartvds]

For a next level version:

We could think about extracting the enhanced features to their own packages and decouple them from grunt (and each other), so they can be reused more easily.

It is a next step after extracting them to the module style.

For example at some point I'd see a semi-persistent compiler server that does the watch and dependency map and then recompiles (or tracks changes for bigger recompile, or even a pull-style compile). It can manage a worker pool, give info of APIs etc.

It would import the other features like we have in grunt-ts (html wrapper, amd loader etc etc) that all don't really have to depend on grunt (or each other). Then we wrap that in grunt, gulp, brocolli etc. It would also make it easier to composite more functionality.

That is a bit far view, but we can move ahead by starting to modularise more TypeScript helpers. I'm doing it for TSD (as side-side project), also first restructuring to modules, then trying to move feature to own packages (in future).

It is for longer term oc and we still have the ts-npm-export codeplex thing open before that.

[jeffmay]

I think this is a great goal for grunt-ts. I think the community would benefit from a central grunt plugin that has a family related plugins. grunt-ts is a great prefix for things like grunt-ts-compiler, grunt-ts-defs, grunt-ts-templates, etc. These can all act independently, but if we need to, they can feature detect each other when needing to do things in a certain sequence.

[Bartvds]

I was more thinking about extracting functionality to regular modules that don't depend on grunt. Then composite them into whatever, like grunt or gulp or custom apps.

Grunt is only a specific wrapper: it is a waste to lock functionality in a plugin, better to extract functionality as a module you can reuse (and test etc).

If we get a handle on exporting dentitions with npm modules it will work nicely typed too.

[jeffmay]

Agree to that too. I think we should unit tests for these things. Moving them into separate modules will make them easier to test and reuse.

Personally, I don't have any plans to move off of grunt, but since the JavaScript world moves so fast, it would be wise to not lose work on this.

[marcuswhit]

Any more thoughts on this? Grunt-TS is great, but Gulp is gaining some good momentum, so would be great if there were a plugin as good as Grunt-TS in the Gulp realm. If most of the code could be reused then it would be a clear win, and wouldn't matter then whether Grunt or Gulp ends up being the defacto standard task runner.

[basarat]

Agreed. My most important task (once I am done with http://www.apress.com/9781484201886) is to make external module loading (from npm / tsd) painless in TypeScript. Once that is done this will be a trivial thing to do.

[Bartvds]

@basarat FYI for this module loading thing: I have some stuff in my dev version of TSD (0.6) that generates a better index file from the DT repos (like http://definitelytyped.org/tsd/data/repository.json but Better). It'll also list what external modules are defined in each definition file, and collates semver versions of files. I want to generate this from a webhook on the DT repo so it is always fresh, and push it somewhere for other tool, like this thing you mentioned just now.