Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove Babel Compilation - Drop Support For Node v4 #608
Starting with the next release (Buzzard) we would like to remove Babel compilation from all server side and React Native modules where appropriate and for modules that can be used in the browser swap over to using Webpack in order to leverage hoisting.
Client side versions of modules are already being moved into their own repos in this release (feathersjs/client#137), so now seems like the best time to do this.
As a result the next Buzzard release will drop support for Node v4 a bit early. Even though there is still 6 months of official LTS left for v4 from Node, we don't believe many people are using Feathers with Node v4.x. Feathers works without compilation on Node v6+ and Node v8.x is the current stable version.
Node has a good migration path so it shouldn't be a blocker for many people if they do need to upgrade and because we use semver Feathers Auk will continue to work on Node v4+ with Babel compilation so migrating current Feathers apps onto new versions of Node is a non-issue.
As a result you should probably start now if you are on Node v4.x.
Why Change This
The @feathersjs/core-team has decided that this is totally worth but if you feel this is cause for concern please let us know! Feel free to comment or simply give a
feathers-hooks-common does need a client build.
Services with memory resident options or that can persist on the client also need client versions. These gain in inportance with feathers-offline-*.
Are there others than feathers-memory, feathers-nedb, feathers-localStorage?
This was referenced
Jul 1, 2017
referenced this issue
Aug 6, 2017
This was referenced
Aug 14, 2017
@bisubus This came up before so let me try and explain why this will continue to be necessary:
Feathers fully supports and encourages ES6 classes and all references Uberproto usage will be removed from the documentation in the future.
However, Uberproto will continue to be used to mix in functionality to existing services. ES6 classes do not support Mixins or multiple inheritance so it is not enough to add e.g. hooks functionality. Instead of always having to safe a reference and overriding the method manually we instead use a tiny library of 86 lines of code with three methods and less than half a kilobyte in size to do that.
@daffl The unquestionable benefit of ES6 classes is that they currently have better support in IDEs for autocompletion, etc (technically, they've got some support while custom inheritance utils have none), even with no JSDoc or TS typings.
The reason why this came up is that I figured out that Uberproto
In my experience, the alternative to Uberproto 'init' feature is to follow the convention that requires to put all initialization logic to
Just wanted to clarify this matter for Buzzard contribution guidelines.