Test failure is due to Node 0.10 not having Map support 😢 will fix in a bit

I want to prioritize this as we're in a moment we can release a new version without any new features in the API or bug fixes.

This will give us some time to check everything.

Test failure is due to Node 0.10 not having Map support 😢 will fix in a bit

With this and the comments I've mentioned above getting fixed I believe we'll be good to roll.

So apparently Rollup doesn't support Node 0.10. Even running with the --harmony flag doesn't seem to work properly. It also looks like Webpack only supports >0.12 versions of Node.

This only really affects the build pipeline. So maybe we can revamp Travis to build using a supported version and then use nvm to change to 0.10 to test against? Ideally I'd like to just drop 0.10 of Node, but LTS doesn't end until October.

Would like your thoughts @leobalter

I'm ok to drop support for 0.10 in this case if that won't represent any problem for other projects using QUnit. This might require a new major version which we could attach the PR dropping QUnit.push so we something else for a new 3.0.0 version.

I think we should definitely slate 0.10 (and probably 0.12 as well) for dropping in QUnit 3.0, but doing that now seems a bit pre-mature since QUnit 2.0 is still new.

Instead I updated the Travis configuration to build against a recent version of Node but to still test against our supported versions. We shouldn't need to support all the same versions for our development/build environment as we do for the distributed version of QUnit.

Instead I updated the Travis configuration to build against a recent version of Node but to still test against our supported versions.

Note that this means you can't have any native dependencies or devDependencies as then you can't install packages with one Node & run them with another one. You're also now using a different npm version to install packages and a different one to run npm test. This seems risky but at the same time I don't see another easy way: you'd basically have to npm install with a new Node, build QUnit, switch to the old Node, re-install all dependencies but retain the built QUnit files and then run the tests.

you can't have any native dependencies or devDependencies

By native, you mean global? Regardless, I don't foresee this being a problem, but good to keep in mind.

you'd basically have to npm install with a new Node, build QUnit, switch to the old Node, re-install all dependencies but retain the built QUnit files and then run the tests.

I would actually be okay with this, except running npm install also runs prepublish which would attempt to re-build the files causing an error and I don't see a good way around that.

Having both src/qunit.js and src/core/index.js seems strange. Otherwise I like the suggestion to move all source files into a src folder.

As for dropping node 0.10, I wouldn't worry too much about it. Whoever is still on 0.10 is probably not going to touch a (current) QUnit release. October isn't far away, might as well drop that immediately. Also, http://qunitjs.com/ only mentions browser support, not node.

Whoever is still on 0.10 is probably not going to touch a (current) QUnit release

The only issue here is that will require a major release (by dropping support) and @trentmwillis pointed it 2.0 has got released recently.

What we can do is land this without a release, focus on the cli (#1024) with a built in reporter and release 3.0.0 when we get all of them done.

Patches (2.0.x) might still have progress for bug fixes, but we would stall QUnit for any minor version (2.1.0+).

This strategy will require us to avoid much further breaking changes, like removing something from the API, allowing us to remote the only method we already have deprecated, .push

If this plan works, we can expect a new major version being released around October, otherwise, we need keep the restraints with 0.10.

I don't understand how dropping 0.10 in our build pipeline is equivalent to a major, breaking change. A few more thoughts there:

• Did we ever officially support 0.10? If not, we're not dropping support
• Is there any actual compat issue with 0.10 with the changes we're discussing? It seems like dropping 0.10 on Travis makes it easier to build/test on all other platforms, but that's it
• Holding off on releases to sprint to 3.0 sounds like a bad idea. I'd like to see js-reporters land as part of 2.x, and that takes time
• Patch releases for old versions can also eat a lot of time. Better to be able to always release from master.

@gibson042, can you give your feedback on this one?

From the main projects I take in consideration for support, we have lodash, which still supports node 0.10. This might be a PITA support to keep, but I would also prefer having more feedback from @jdalton.

I'm cool with whatever you all need to do. Lodash will drop Node 0.10 support in v5 (Jan 2017). I only ever use the QUnit dist build though so changes to your build requirements don't affect my use.

Ok, the way @trentmwillis fixed the CI process, it looks good to me landing this PR.

Having both src/qunit.js and src/core/index.js seems strange. Otherwise I like the suggestion to move all source files into a src folder.

I like the src/qunit.js as the starting point. We can move the src/core/index.js to a better naming in a follow up.

Is there any actual compat issue with 0.10 with the changes we're discussing? It seems like dropping 0.10 on Travis makes it easier to build/test on all other platforms, but that's it

@jzaefferer exactly. This "drop" was primarily talking about our build/testing processes. The distributed library itself should still work in Node 0.10.

@leobalter I would like to hammer out what we want our Node support policy to be. We currently have a "rolling" support policy for browsers and I tend to think we should probably adopt something similar with Node. Ex: we support Node LTS releases, but any QUnit released after LTS ends is not guaranteed to be compatible (similar to how we don't test against all versions of Chrome since 2.x was released, we only care about the 2 most recent). That way, when 0.10 LTS ends in October we can drop it without having to do a major version bump.

As for the file structure, we can debate that when I open the PR to make the change.

surprisingly we have no specific support mentioning Node 0.10. We can't say we actually had any support as some previous versions of QUnit didn't work on Node at all.

Similar to the browsers I want to say we should support the last 2 LTS versions if more than one is active. That would target us to Node 4 and 6. At some point this will make more sense.

The alternative is to say we support the current Node LTS versions from the time of each release.

Similar to the browsers I want to say we should support the last 2 LTS versions if more than one is active. That would target us to Node 4 and 6.

Currently that would target 0.12 & 4, not 4 & 6. Node 6 is not an LTS, it will become an LTS at the time of Node 7 release (around October, half a year after the 6.0.0 stable release).

https://github.com/nodejs/LTS

There's only one LTS and one stable at a time, right? That's two versions, similar to Chrome's last two versions support. So Node 4 and 6, right?

I don't know if we really need to support two LTS versions plus a stable, do we? (Honestly not sure, not trying to persuade folks.)

@platinumazure No, there are more supported versions. Just click the link I provided, it's all explained there.

A couple of nits, but on the whole this looks great! 👏

Updated to address @gibson042's comments.

I think we should land this. Since we have no official Node support policy as of this moment, I don't see a need to do a major version bump. Additionally, we're only dropping Node 0.10 from our build environment which should not concern our consumers.

I do think we should figure out an official policy for Node support, but we should likely do that in a separate issue.

Woops, looks like Node 0.10 and 0.12 don't like the template literal in the rollup config. Changing it back...

I know this is bikeshed-y, and a bit after the fact, but I'm curious why the choice to go with Rollup?
I've found Webpack to be super flexible for builds.

@jdalton honestly, we could have gone with either. After looking at both Webpack and Rollup, they both support everything that we need. I wound up choosing Rollup because it seemed to more closely align with the architecture of QUnit, in that we only have one real module we distribute. We hope to change that in the future so that Node users don't need all the Browser-specific code, but even then we're still only likely to have a small handful of modules. Rollup also seemed a bit easier to get up and running.

At the end of the day, the primary goal is to support ES6 and start using a standard module syntax, so if needed we could switch to Webpack (or some other tool) in the future.

I have no objection to landing this.

@leobalter would like your 👍 before landing.

👍 let's do this!

For a heads up on the rollup/webpack, I agree with the answer from @trentmwillis. I believe it should not be any problem to switch it later. I have some experience with webpack but I'm interested to try rollup for now.

Merged, but build error'd. Not sure why, investigating now...

Update: there was a back-compat issue in Babel that messed up the preset for es2015. Find out more in this issue: rollup/rollup-plugin-babel#72

Gotta hang tight until a new release is cut. At which point I'll kick the build again.