Build: Rearrange grunt/npm tasks into a build/dist/test pattern

[gibson042]

Ref 76df9e4
Ref #1949 (comment)

[mgol]

I've just noticed this will most likely not work on Windows unless run via Bash. This also affects current build script definition.

cc @dmethvin

[scottgonzalez]

This will work fine. You might want to read http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/#thewindowsproblem

[mgol]

Ah, OK then. I must have remembered sth incorrectly.

[dmethvin]

I use msysgit and bash on Windows, can't imagine getting work done without it. Even if our own stuff works I'd be concerned that something would be amiss in the 27-bazillion levels of npm dependencies below us. However, we pulled out the README instructions for installing msysgit a while back and nobody has come in to say they can't get things up and running on Windows. Not sure what that means, maybe I'm the last Windows user.

[dmethvin]

👍

[mgol]

LGTM, too. If we ever want to make Node smoke testing optional, we can tweak the setup further.

@markelog didn't want to have this smoke testing run on every grunt execution so I'd like to hear his opinion as well. But it seems most is in favor of it.

[markelog]

So at grunt test we would not lint anything? But ci-run will execute those tests twice?

This:

grunt.registerTask( "test_fast", [ "node_smoke_test" ] );
... 
grunt.registerTask( "test", [ "test_fast" ] );

Is look like very weird, test is test_fast and test_fast is node_smoke_test, confusing, i assume, this is done for the future but it looks pretty incoherent to me.

Whereas this node_smoke_test just require stuff, not running qunit tests, i don't see the point doing this everytime for the default task, you will find more issues with your code with jshint task, not with this one, this smoke stuff could find the problem but in very rare cases. For me, it would be even okay, if we would run it before the release, certainly not everytime, but that's me.

I feel we redoing a lot and make arguably confusing changes for very small benefit. I'd create an npm command, that runs this jsdom require and execute it with ci-run or even without npm command and only with grunt task just like grunt testswarm

[gibson042]

So at grunt test we would not lint anything?

Right; testing and linting are separate processes.

But ci-run will execute those tests twice?

The fast ones, yes. Or we could introduce a currently-empty test_slow (for eventually population by the full test suite) and use that to avoid duplication. The goal here is to set up a basic structure: lint (preceded by build for us because our source is deconstructed), output to dist (including minification/tree-shaking/etc.), test the result.

[markelog]

Probably better to register it above the "dev" task

[markelog]

I think it would fine if have something to structure, now we only have this require and couple tasks that do this require, that do the same thing, "test_fast" name doesn't make sense, at least now.

[gibson042]

"test_fast" name doesn't make sense, at least now.

As it turns out, #1821 or #1996 or similar will introduce such a need... node_smoke_test is fast, but promises-aplus-tests is slow.