yoshuawuyts / es2020 Goto Github PK

View Code? Open in Web Editor NEW

126.0 11.0 14.0 25 KB

Because in hindsight we don't need most of ES6

License: MIT License

JavaScript 100.00%

es2020's Introduction

es2020

browserify transform that compiles a selection of ES6 features to valid ES5:

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

Because, in hindsight, we can do without most of ES6.

Usage

Via package.json (recommended):

{
  "browserify": {
    "transform": [
      "es2020"
    ]
  }
}

Via CLI:

$ browserify client.js -t es2020

Via Node API:

const browserify = require('browserify')
browserify('./client.js')
  .transform('es2020')
  .bundle()
  .pipe(process.stdout)

FAQ

Is this a joke?

Not really. The TC39 does not represent my interests, and the features they introduce are not useful for the stuff I'm doing. I'm bloody serious. A few good things have been introduced, so that's what we're backporting to older browsers.

Can you not?

If the TC39 had an open standards process perhaps this wasn't needed. But as it stands they're an unwelcoming club, so I get to poke fun at this situation that otherwise fills me with sadness. Feel free to poke fun at me too. Or if you're angry that someone would make fun of the hard work the TC39 has done, feel free to ignore this project. Do whatever, I'm doing the same.

Can you include feature X?

Maybe. Open an issue, make a case and we can discuss it. Just remember that this project is not democratically governed.

Installation

$ npm install es2020

License

MIT

es2020's People

Contributors

Stargazers

Watchers

Forkers

ramongebben kemitchell ajoslin ahdinosaur 0xr krawaller yuttasakcom

es2020's Issues

Object shorthand notation

With shorthand notation for object composition you save the developer the effort of rewriting key value after the key when key and value have the same name. Instead of writing

const myVar = "pizza"; 
const myObj = { myVar: myVar };

You would write

const myVar = "pizza"; 
const myObj = { myVar };

Which would generate the same.
I use this all the time in for instance redux action creators for the payload.
By example:

export function myAction(payload) { 
  return { type: 'my:action', payload } 
}

EDIT: My phone screwed up markdown

Default parameters

I think default parameters are preferable to common patterns such as:

Compact, but loosey goosey boolean coercion

function foo(bar) {
  bar = bar || 'baz';
}

Explicit, but ugly

function foo(bar) {
  bar = typeof bar !== 'undefined' ?  bar : 'baz';
}

I think default parameters are much more explicit and avoids a mutating assignment:

function foo(bar = 'baz') {

}

In conjunction with object destructuring you also have a nice defaults pattern:
https://gist.github.com/ericelliott/f3c2a53a1d4100539f71

Of course you can always use xtend but the compactness is nice.

Openness and outreach

Great project—I suspect you will all learn and build some excellent things. I just wanted to respond, in the most sincere way, with a few resources for everyone here to check out:

http://github.com/tc39/agendas is the repo where all meeting agendas are posted and created over the 2 months between each meeting. Here is the agenda for next week: https://github.com/tc39/agendas/blob/master/2017/01.md
https://github.com/tc39/test262 is the open source repo containing all of the spec conformance tests—these are also written in JS. Contribution only requires signing a CLA (very much like most large open source projects)
https://github.com/tc39/process-document is home to the source of the TC39 Process Document which concretely defines the steps taken to bring features/fixes/changes etc from proposal to published specification.
Here is a list of all proposals, both active and inactive:
https://github.com/tc39/proposals is where you'd look if you want to see the progress of the proposals "at a glance" (ie. stage, activity, etc).
https://github.com/tc39/tc39-notes is sync-ed fork of my own meeting notes dating back to May 2012. This material is a bit dense, but I hope it accurately captures the discussions, motivations, reasons and rationales. It's also a good place to track the history of specific features as they evolved from proposal to specification. This is so open that it contains the Ecma legal stuff from every meeting, as well as the names of every person in attendance.
https://github.com/tc39/ecma262 is the big one! That's the actual spec source itself, contributions are subject only to CLA signature.

Ok, that's all! I hope you find the resources helpful :)

Object destructuring

One of the features I use very often is Object destructuring.
It would be awesome if you could include this as well.

destructuring

totally agree on the subset approach (as with ES3 - i.e. no with, no eval and so forth)

However I would advocate destructuring, it's both a useful shorthand and injects
helpful explicitness into the function signature

const fn = ({foo, bar}) => (foo + bar)
fn({foo: 1, bar: 2}) //3

app.js:56628 Uncaught TypeError: yo is not a function

For now, we just turned off es2020, but it'd be nice to have it so we can use uglifyjs with yo-yo

/cc @laurengarcia

spread

spread can be useful, it reduces noise, commonly associated with an immutable approach

// returns fresh state object based on input
function move(input) {
  const payload = input.payload
  const action = input.action
  const x = payload.x
  if (action === 'up') return {...payload, x: x + 10}
  if (action === 'down') return {...payload, x: x - 10}
}

equivalent:

// returns fresh state object based on input
function move(input) {
  const payload = input.payload
  const action = input.action
  const x = payload.x
  if (action === 'up') return Object.assign({}, payload, {x: x + 10})
  if (action === 'down') return Object.assign({}, payload, {x: x - 10})
}

errors when configured via `package.json`

TypeError: Cannot read property 'debug' of undefined
    at DestroyableTransform.end [as _flush] (/.../node_modules/es2020/index.js:32:33)

because browserify is not passing opts._flags to the transforms if they are configured via package.json, which is an existing bug i've raised and fixed, but has yet to be merged and published.

so maybe while we wait, we should default to something so it doesn't break?