Discussion: improve guidelines with JS engine support and target ES version

[mroderick]

Hello folks!

Disclaimer: I think that the topics discussed in this issue are closely related and it makes sense to discuss them together. If it turns out to be too confusing, then we can split this into several issues and discuss topics separately.

Solid guidelines makes it much easier to contribute to projects.

As we are gaining traction with more contributors, it is becoming even more important to give good guidelines and explain our aims.

ES version in source

ES5 has been out since 2009, it is backwards compatible, easy to polyfill and generally has very good support in popular JS engines.

I think it is time to commit to using ES5 as the official version for Sinon's source.

We should update contribution guidelines to state that we prefer ES5 and ES5 idioms. We should update the ESLint settings (and eventually add plugins) to support this choice as best it can.

If we run into issues with specific runtimes when using ES5 (hello Rhino), we can come up with strategies to support the troublesome engines, like we have in the past.

http://kangax.github.io/compat-table/es5/

Are there any objections to using ES5 in strict mode as our official target for the source?

JavaScript engine support

On http://sinonjs.org we claim that the following engines are supported

• IE6+
• Firefox 2+
• Chrome 7+
• Opera 10.10+
• Safari 3.2+
• Mobile Safari 3.2+
• Android 2.1+
• NodeJS 0.2.x+

If we decide on going with ES5 as suggested above, then we need to bump minimum supported versions of most of these runtimes.

In master we are using some ES5 features already, which leaves at least old IE out in the cold. I suspect that several of the other browsers are also not supported by the code in master.

For the first stable release of Sinon 2, we should revise the supported engines list and try to run tests in the engines that we claim to support.

What JavaScript engines and versions do you think we should target?
How do you think we should communicate this?
Shall we make a compatibility page on the new site, showing the different support levels by Sinon major releases?

[mroderick]

Ping @fatso83 @mantoni @fearphage @jonnyreeves @cjno

[mantoni]

👍 ES5. I don't think its worth the effort of a compatibility page. Maybe just a short note that Sinon 2 requires ES5. If anyone needs old IE support, they can stick with Sinon 1.17.x. Let's move on.

I didn't follow browser market share developments lately, because I'm mainly doing backend work. However, given that we want ES5 as the baseline, we can still support "old" Node versions without additional work. To reduce testing effort, we could claim to support Node down to 0.10 or 0.12?

[fatso83]

I agree we should target ES5 runtimes, but I am not sure about the need to commit to ES5 in source. To elaborate, we have already committed to using a build step, and I don't see why we cannot utilise Babel to do ES2015=>ES5 transforms in this build step. We would still target ES5, while increasing developer satisfaction due to not having to reimplement all the goodies included with ES6. Axel Rauschmayer has a nice setup for static transpilation on Node with working source-mapping. We don't have to touch any of the existing code, but this would make it possible to gradually convert the codebase using nice syntactic improvements.

[mroderick]

So far, I have not had the privilege to work on a project where I would consider a transpiler to be a net benefit. My experience has been that they mostly get in the way, and create more work, especially debugging weird mismatch between their dependencies.

I did a quick test, adding babel and babel-cli to an empty project added 190 packages in node_modules.

It has been my experience that people often argue for transpilers with the argument that it makes them more productive. However, they mostly focus on writing/typing when talking about productivity. I think we should optimise for reading and comprehension. My experience has been that transpilers make comprehension and debugging harder, not easier.

If we decide to add a transpiler, we would have to do so very carefully, which means locking down all dependencies using npm-shrinkwrap.json / yarn.lock.

I think we can all agree that using ES5 Strict (which we pretty much are already) is much less risky than introducing a transpiler in our setup.

Can we do commit to ES5 Strict first, and then decide on if/how/when to use a transpiler on the other side of getting 2.0 released?

[mantoni]

I couldn't have expressed my thoughts better than @mroderick. I have similar experiences, and even some bad experiences with export/import in combination with Sinon stubs. It would make sense for a pure browser project, but with Node, I'd rather stick with the platform language support. Anyway, I'm not really contributing to the Sinon codebase at the moment, so I don't want to stand in the way either.

[jonnyreeves]

I echo the sentiments of @mroderick (and like @mantoni am not terribly active on this project) - the only thing I might add is that TypeScript may offer some benefits (although, sinonjs, by nature, is highly dynamic :D)

[fatso83]

I really have no strong feelings on this subject, it was more like a suggestion that was up for discussion. I agree on the complications, and I am fine with ES5.1, so it seem this will form the basis for development in Sinon 2. We can revisit this discussion on major EcmaScript increments to see if things change.

[mroderick]

OK, ES5.1 for source, I'll create a PR to update guidelines.

What about the question of JavaScript engine support?

What JavaScript engines and versions do you think we should target?
How do you think we should communicate this?

Does anyone have any opinions on this?

[mroderick]

This was fixed with 5874b0e