Adopt ES2015+ features in Unified collective

Closes Gh-4.

Reviewed-by: Merlijn Vos <[email protected]>
Reviewed-by: Christian Murphy <[email protected]>
Reviewed-by: Titus Wormer <[email protected]>

text/0000-javascript-2015-2019.md

@@ -0,0 +1,92 @@
+*   Start date: 2020-04-05
+*   Scope: Collective
+*   RFC PR: <!-- leave this empty -->
+*   Implementation issue(s): <!-- leave this empty -->
+
+# Summary
+
+Adopt JavaScript 2015-2019 syntax supported natively by Node.js where appropriate.
+
+## Basic example
+
+An example of a library updated to leverage ES2015-2019 features can be seen here <https://github.com/vfile/vfile-message/pull/8>
+
+## Motivation
+
+There are two goals:
+1. Easing contribution for new members
+2. Allow for additional instrumentation and tooling
+
+### Easing Contributing
+
+The [State of JS survey 2019](https://2019.stateofjs.com/), indicates that 85-90% of JavaScript developers have used ES2015 features [[1]](https://2018.stateofjs.com/javascript-flavors/es6/), which holds consistent with the 2018 results where 86.3% indicated they had used it and would use it again [[2]](https://2018.stateofjs.com/javascript-flavors/es6/).
+
+### Additional Instrumentation and Tooling
+
+Tools like ESLint provide additional analysis for features using ES205-2019 syntax. [[3]](https://eslint.org/docs/rules/#ecmascript-6) [[4]](https://github.com/xjamundx/eslint-plugin-promise)
+
+## Detailed design
+
+Leverage ES2015+ features where applicable with Unified:
+* [`class`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/class) for representing classes
+* [Default parameters](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Default_parameters) to represent default values
+* [`let`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let) and [`const`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const) for block scoped variables
+* [Arrow functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions) where `this` cannot/should not be changed with [`.bind`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind)
+* [Rest parameters](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters) for representing an arbitrary number of parameters ([arguments](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments))
+* [Promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) for values that may resolve later (already used in Unified)
+* [Async Await](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) syntax for Promises
+
+Platform support for these features can be seen at:
+* <https://kangax.github.io/compat-table/es6>
+* <https://kangax.github.io/compat-table/es2016plus>
+
+The features listed above are supported on:
+* Node 8, 10, and 12 LTS
+* Chrome, Edge, Firefox, and Safari
+
+## Drawbacks
+
+There are two main drawbacks:
+1. Changes are primarily internal
+2. Legacy support
+
+### Changes are Primarily Internal
+
+These changes would not change the public API of Unified, VFile, Remark, etc.
+This would be a set of internal changes which could benefit maintainability long-term, but would not have an immediate benefit for downstream adopters.
+
+### Legacy Support
+
+While many browsers and all active release lines of Node support ES2015-ES2019.
+Not all platforms do, Nod.js 4 and earlier, Internet Explorer browser, and [Rhino](https://github.com/mozilla/rhino) do not fully support ES2015. [[5]](https://kangax.github.io/compat-table/es6/)
+To continue use on these platforms code would need to be transpiled to ES5, using [Babel](https://babeljs.io), [TypeScript](https://www.typescriptlang.org/), or a similar tool.
+
+## Alternatives
+
+What other designs have been considered?
+What is the impact of not doing this?
+
+## Adoption strategy
+
+> If we implement this proposal, how will existing unified developers adopt it?
+
+These changes would mostly be internal, most public APIs would be completely unchanged, APIs that do change, would likely have subtle changes.
+
+Adoption of this would take a bottom up approach, starting at the lowest level dependencies (vfile, vfile-message, etc), working up to the shared libraries (unified, unified-engine, etc), then into the language specific tooling (remark, rehype, retext, redot, etc).
+
+> Is this a breaking change?
+
+This is open for debate since Unified does not have an explicit browser/Node support matrix.
+These changes would be primarily non-breaking, we could mark them as breaking to communicate the implicit change in support matrix.
+
+> Can we write a codemod?
+
+There is an existing codemod that can help with this <https://github.com/lebab/lebab>
+
+> Should we coordinate with other projects or libraries?
+
+This would primarily be internal.
+
+## Unresolved questions
+
+- [ ] Would this be considered a breaking change?