A few items to consider (and possible pull requests)

[brian428]

Minko, I just wanted to relay a few minor tweaks I've made to my project to see if you'd have any interest in seeing pull requests for these:

• A separate watch-start.build.dev Gulp task that runs only once during serve.dev. This way, extra tasks like clean and tslint will run once, but afterwards the faster build.dev is run on subsequent watch triggers.
• A separate build.test.quick Gulp task that is run during Karma watch triggers. This one omits the tslint to speed up the test build.
• (In reference to both of the above) Those might be better handled with a tslint.once task, so that linting can run, but only once?
• Applying the same TYPED_COMPILE_INTERVAL from the build.js.dev to build.js.test to further speed up the test compile.
• I have a simple code generator task working, using node-plop. It's not amazing but I do find it handy to spit out components+specs, services+specs, update some index.ts files, etc. Not sure if you'd actually want to include this with the seed, because the type of code one wants to generate probably differs alot between developers, but it could be a wiki page topic.

[mgechev]

Thanks for the suggestions, I really appreciate discussions aiming to improve what we currently have!

A separate watch-start.build.dev Gulp task that runs only once during serve.dev. This way, extra tasks like clean and tslint will run once, but afterwards the faster build.dev is run on subsequent watch triggers.

Running clean.dev before serve.dev definitely makes sense, not sure about tslint. I believe text editors are the tool to report/autofix linting errors, which also helps us speed up the build.

A separate build.test.quick Gulp task that is run during Karma watch triggers. This one omits the tslint to speed up the test build.

It makes sense to drop tslint from build.test!

I have a simple code generator task working, using node-plop. It's not amazing but I do find it handy to spit out components+specs, services+specs, update some index.ts files, etc. Not sure if you'd actually want to include this with the seed, because the type of code one wants to generate probably differs alot between developers, but it could be a wiki page topic.

node-plop sounds like a great suggestion. What bothers me is that we'll expand the scope of the project a lot which will introduce additional complexity and a lot of feature requests. We will later need to introduce AST tools for generation of routes and basically we'll go into the direction of the CLI.

What do you think about introducing clean.dev as first task of serve.dev, drop tslint from build.test and

Applying the same TYPED_COMPILE_INTERVAL from the build.js.dev to build.js.test to further speed up the test compile

[brian428]

Sorry for the delay, Minko. I'll try to look at these items (dropping tslint from build.test, adding the compile interval to build.js.test, and adding clean.dev to the servie.dev sequence) in the next few days.

My only thinking with running tslint once when starting a serve was just to provide that info at least once. It only slows the serve task by a few seconds, and only does it one time. Text editors are the ideal place to identify things like that, but with a large codebase it's easy to have sections of code that aren't looked at frequently, which doesn't give an IDE/editor much of a chance to flag problems. Since tslint includes the whole codebase, it seemed like a worthwhile sanity check.

[mgechev]

My point against running tslint before you run the production build and server is that at this point you're in the beginning of a coding session which will, most likely, introduce new linting errors. I'm also trying to keep the set of tasks as small as possible, that is why I suggested making modifications to already existing ones instead of introducing new.

What do you think? Does this make sense?

[brian428]

Sure, makes sense. I was just trying to expand on my logic. No worries! :-)