|
| 1 | +| Title | Invert dependency of readable-stream | |
| 2 | +|--------|--------------------------------------| |
| 3 | +| Author | @mcollina | |
| 4 | +| Status | DRAFT | |
| 5 | +| Date | 2017-01-26 12:00:00 | |
| 6 | + |
| 7 | +## Description |
| 8 | + |
| 9 | +The `readable-stream` module is one of the most popular modules on NPM, |
| 10 | +with 33 million downloads per month. `readable-stream` is the basis of |
| 11 | +most of the ecosystem utilities for manipulating streams, as it provides |
| 12 | +a consistent API across all the different versions of Node.js and the |
| 13 | +browser: from Node.js v0.8, and IE 9 and Safari 5 as the oldest browsers. |
| 14 | + |
| 15 | +`readable-stream` was introduced to help module authors build the |
| 16 | +streams ecosystem across the different versions of Node.js, backporting |
| 17 | +v0.10 streams to v0.8. |
| 18 | +The code for the `'stream'` module in core *depends on the version of |
| 19 | +core* that is being used, and because streams users inherits from |
| 20 | +classes like `Readable`, `Writable` or `Transform` a tiny difference |
| 21 | +might make a program work on a version of Node but not in another. |
| 22 | +Module authors appreciate the stability `readable-stream` provides, |
| 23 | +and it is currently in the dependency tree of gulp, mysql, mongodb, webpack |
| 24 | +and many other highly-popular libraries. |
| 25 | +A good article for what `readable-stream` provides can be found at |
| 26 | +https://r.va.gg/2014/06/why-i-dont-use-nodes-core-stream-module.html. |
| 27 | + |
| 28 | +`readable-stream` is an export of the latest stream API from the Node.js, |
| 29 | +done via a mixture of babel transpiling and regular expressions. The export |
| 30 | +means that `readable-stream` has to follow the Node.js release cycle, and it |
| 31 | +is not versioned independently. Specifically, versioning of `readable-stream` |
| 32 | +is extremely hard, as *we are currently not bumping major* |
| 33 | +to avoid breaking many packages and maintaining multiple lines. The current |
| 34 | +situation is not ideal, as `readable-stream` passively follows what is merged |
| 35 | +in Node.js. |
| 36 | + |
| 37 | +At the moment `readable-stream` does not have its own documentation, it is the |
| 38 | +documentation of whichever version of Node.js is built from. This creates confusion, |
| 39 | +as the latest `stream` from Node.js supports some features that cannot be ported |
| 40 | +to all versions of Node.js. |
| 41 | + |
| 42 | +This EP proposes to invert that dependency, and have Node.js include |
| 43 | +readable-stream from the `deps` folder. |
| 44 | + |
| 45 | +## SEMVER for streams |
| 46 | + |
| 47 | +As things stands right now, `readable-stream` support Node.js from v0.8 |
| 48 | +upwards, and fairly ancient browsers versions as well. Because of this, |
| 49 | +we are currently using babel (and a bunch of regexps) before release, |
| 50 | +to support ES5-based vendors. Dropping support for any of those is a |
| 51 | +semver-major change, and given the massive amount of dependencies, it |
| 52 | +might have a semver-major ripple effect throughout the ecosystem. |
| 53 | +In order to avoid a lot of work for maintainers, we aim to minimize those. |
| 54 | +At the time of this writing, we plan __not to bump__ semver-major in 2017. |
| 55 | + |
| 56 | +We recognize that the ecosystem is changing at a fast pace, and at some |
| 57 | +point we would have to bump the major. If we decide to do that, we would |
| 58 | +have to manage two release lines (or more), and backport changes from |
| 59 | +Node.js streams to **both**. As things are now, this is highly |
| 60 | +impractical to do, and it would be much easier to manage if `readable-streams` |
| 61 | +could manage its own versioning. |
| 62 | + |
| 63 | +## Process / Timeline |
| 64 | + |
| 65 | +1. move the code of streams into `readable-stream` |
| 66 | +2. amend the build script for the NPM/ecosystem build |
| 67 | +3. rewrite the tests to easily check against both the node |
| 68 | + source folder and old versions of Node.js and the browser. |
| 69 | +4. port the Node streams documentation to `readable-stream`; a _copy_ |
| 70 | + of the docs will be maintained in Node.js. |
| 71 | +4. merge back all changes that happened in the meanwhile, and sync up |
| 72 | +5. add `nodejs/readable-stream` inside deps of Node.js, and remove the streams |
| 73 | + implementation; to avoid any possible disruption, this will be a |
| 74 | + _semver-major_ change for Node.js. |
| 75 | +6. bump *minor* version of `readable-stream`. |
| 76 | + |
| 77 | +## Challenges |
| 78 | + |
| 79 | +1. export git history from node.js |
| 80 | +2. handling issues between the two repositories |
| 81 | + |
| 82 | +These challenges need to be adressed with the rest of the node collaborators. |
| 83 | + |
| 84 | +## Role of the Streams WG |
| 85 | + |
| 86 | +The Streams Working Group will still be responsible for maintaining |
| 87 | +`readable-stream` and `'streams'` in core, and this EP does not change |
| 88 | +anything. However, the role of `readable-stream` is to |
| 89 | +`'port stream to older node versions and browsers'`, while after the |
| 90 | +inversion of dependency, it would change to `'support Node.js streams in |
| 91 | +throughout the different versions of Node and browsers'`. |
| 92 | +As it is right now, the Streams WG commits in maintaining the |
| 93 | +performance of streams within Node.js. |
| 94 | + |
| 95 | +## Target version of Node |
| 96 | + |
| 97 | +We think we should target this to be shipped in Node 8. |
0 commit comments