use es2040 for browserify transform and linting

davidmarkclements commented 7 years ago

https://www.npmjs.com/package/es2040

This enforces a subset of useful ES6 features and prevents the others by matter of course

Transpiles this es6 subset for older browsers (obviously faster because it's more focused)

No need for a server side transpile step - all of es2040 is supported in v6

It could be useful to figure out a way to make it a secondary linter (after standard) - maybe start with something simple as attempting to transpile and then "oops that's not es2040"

ES2040 supported features:

fat arrows - make inline functions cute-looking
template strings / tagged templates - enable DSLs inside of JS
const - using const by default makes it easy to spot where values are being redeclared
object destructuring - const { a, b } = { a: 1, b: 2 }
array destructuring - const [a, b] = [1, 2]
default parameters - ({ a = 1, b = 2 } = {}) => a
rest parameters - (a, b, ...args) => {}
spread literals - f(a, b, ...args)
short-hand properties - return { a, b }
computed properties - return { [a]: b }

If we want to be even more strict, we could go with ES2020 is:

fat arrows - make inline functions cute-looking
template strings / tagged templates - enable DSLs inside of JS
const - using const by default makes it easy to spot where values are being redeclared

Which would be probably be wicked fast at transpiling.

In either case, much faster than babel.

Thoughts? @mcdonnelldean @lucamaraschi @mcdonnelldean @mcollina

mcollina commented 7 years ago

Why do we need to transpile/browserify here? We just need to run browser tests. The target application will transpile, and it's their decision.

As for what is supported here, targeting node v4+ is a must, so we are limited to what is there.

lucamaraschi commented 7 years ago

I agree with @mcollina

davidmarkclements commented 7 years ago

In that case (v4 support) we could still go with es2020, at least have const, template strings and fat arrows, and add es2020 as browserify transform in package.json - when a user browserifies at the app level browserify will know to use es2020 transform for our lib. This can be independent of their choice to transpile.

But it may be a bit too much of an investment (figuring out usage edge cases) to justify the three features. Template strings is mainly what I'm wanting

davidmarkclements commented 7 years ago

have come to conclusion that we're better of staying simple for infrastructure - agreed

apparatus / mu

use es2040 for browserify transform and linting #31