Improve build process

[Rich-Harris]

Following #1485, there are a few tasks:

• fixing https://github.com/Rich-Harris/esperanto/issues/15, since we can't use named imports/exports otherwise (results in conflicting variable names)
• figuring out how to stop 6to5 from adding a 'use strict' directive to every file
• getting sourcemaps up and running
• rewriting or separating all the tests that test (or rely on) individual modules, or overwrite them. Having these unit/integration tests in the same suite as the end-to-end tests means having to create a bundle and all the one-to-one transpiled AMD modules
• general tidy up of the gobblefile and grunt tasks
• add back noConflict

Once that's out of the way, there are a few things we can do to tidy up the source code itself, some of which will decrease file size (using Esperanto instead of RequireJS+AMDClean already reduces the minified filesize a bit, but there's more we can do)

[evs-chris]

figuring out how to stop 6to5 from adding a 'use strict' directive to every file

Try adding blacklist: ['useStrict'] to the params.

[Rich-Harris]

@evs-chris /slaps forehead, ticks checkbox

[evs-chris]

I'm thinking of taking a stab at #1252. Would anyone be opposed to switching to Mocha, having individual test modules be UMD, and having a big aggregate UMD test suite for the grunt build to run?

QUnit is broken in-browser for me right now, and I don't know about everyone else but AMD hurts my head a little. I think it may lower barrier to entry (#1251) a little to not use require.js for tests and the sample dev page. I have tried out using the Ractive bundle in samples and tests along with the sourcemaps, and (in Chrome) you get a nice AMD-ish experience albeit with a strange absolute path for the Ractive source (see gobble-relative-sourcemaps?).

So, I'd like to:

• switch to mocha
• maybe break the tests into something that more closely resembles the source tree?
• have module test suites live as es6 modules in the test directory and have gobble package them up individually and as a bundle for general or targeted testing
• have the tests be esperanto-bundled as UMD to avoid require.js, since there're only the runner, blanket, the Ractive bundle with sourcemappingurl, maybe a helper, and the tests to load - this has the potential benefit of putting local dev/testing on exactly the same platform as what is published
• let gobble generate the individual module test pages, rather than grunt
• whilst twiddling about with tests, look into JSDom and/or other similar packages [1]
• ???
• profit

Does that sound like an agreeable path forward?

Taking it a step further, is there a reason not to replace grunt with npm scripts?

[1] JSDom still requires gyp, which is awful for those unfortunate enough to have to run directly on Windows. I'd actually prefer the default method of testing to be in-browser and to remove phantomjs as a devDependency in the main package.json. Headless testing could be built into a build script using a sub-module (directory with its own package.json) for deployment checks and Travis. That would make getting started on Windows a thousand times easier and let those of us who use node 0.11 most of the time not have to switch back and forth to 0.10 (I have yet to get the phantomjs bindings to build with 0.11).

[Rich-Harris]

Strongly in favour of all of this!

The only hurdle I can see to ditching AMD is that some of the tests depend on individual modules, which might make stuff awkward - though I guess if each test module gets bundled and UMD-ified, and Ractive itself is skipped during that bundling process, then that wouldn't be too difficult to overcome.

Sourcemaps are still a little wonky since there are multiple steps (6to5, bundling, and ultimately minification) - in theory sorcery will give you accurate mappings back to the source, though in practice.... It does also make IE bugs harder to debug, though we could mitigate that by annotating the bundled source code with module paths. Will open an issue on Esperanto.

Definitely don't think we'd regret replacing PhantomJS with JSDOM. (Though I didn't realise it still requires gyp. I don't know how Windows people get any work done!) @rstacruz has our back: https://www.npmjs.com/package/mocha-jsdom

Taking it a step further, is there a reason not to replace grunt with npm scripts?

Nope.

[evs-chris]

Sourcemaps are still a little wonky

I have noticed that Chrome will jump to the wrong spot in the mapped file every now and then. In some situations, it will just jump to line 1. For init breakpoints/exceptions, it looks like Chrome is still preparing the map when it drops you on a line, so you end up offset by the UMD boilerplate when it does finish with the map. Overall though, it's pretty ok.

Definitely don't think we'd regret replacing PhantomJS with JSDOM.

It's looking like JSDOM isn't quite complete enough for our test suite, and I've only gotten to the event tests (alphabetically). I'm looking at 29/328 failures where everything is happy in-browser for the most part. Note that Mocha only counts actual tests and not assertions like QUnit.

Though I didn't realise it still requires gyp

It does, but only for contextify, which is waaaay less painful to build than phantom.

I don't know how Windows people get any work done!

Without VirtualBox or some equivalent, I'd be entirely without hair.

I haven't found anything like htmlEqual for Mocha, so there are some oddities here and there depending on what browser you're using. IE apparently does namespaces a little differently, so it fails a test that Firefox and Chrome are ok with for SVG. It's easy to work around, though.

Since Mocha has a built-in grep to narrow what tests you want to run, I vote we skip having tests for individual modules and just use the main page. That would eliminate the odd module test page generation step. It's kinda nice to be able to expand the test to see the code in it right in the browser.

I'll try to get the rest of the tests ported over and a demo branch up tomorrow. I'd like to get some feedback and maybe see if someone else can get JSDOM to cooperate.

[Rich-Harris]

I haven't found anything like htmlEqual for Mocha

Actually I ended up hand rolling that one - there was an existing plugin but IIRC it behaved strangely in some situations (or maybe didn't like SVG, or something). So it should be possible to just use this, except using whatever assert.deepEqual() is handy.

I vote we skip having tests for individual modules and just use the main page

Makes sense. So we'd use something like ?module=events in the URL?

[evs-chris]

I ended up hand rolling that one

Nice! I completely missed that.

So we'd use something like ?module=events in the URL?

?grep=whatever It will find any tests that have whatever in their name, regardless of suite. It's kinda nice for testing something like transitions, where the tests may be in multiple suites. But you can't target a specific suite unless you name them with some sort of unique identifier.

It seems that some of the test suite is not liking the transition because everything was good up to magic and then on merge and misc, already passing tests started failing.

[Rich-Harris]

Will close this issue as most stuff is now taken care of. noConflict has been removed since 0.6.1 because the new build process only registers Ractive as a global in the absence of a module system - both those things can be patched if it turns out people actually need them.

Still interested in using mocha everywhere, as it has some nice features, but I reckon that's a separate issue. In any case, there's currently a real dealbreaker in the form of mochajs/mocha#553 - there's no equivalent of QUnit's notrycatch option, which means you get a useless non-interactive non-sourcemapped stack trace in the browser, rather than a proper one in the console.