Remove Babel Compilation - Drop Support For Node v4

[ekryski]

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-ecosystem/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

• We will be able to install modules from a github repo. This will make it easier for people to have private forks and contribute fixes. 🎉
• Reduced dependencies are always great 🙌
• Easier debugging and less code bloat
• Less tooling to maintain
• No need for people to compile and/or watch files when developing, testing modules, etc.
• We're currently restructuring some modules and breaking out client builds into their own repos

What Changes

• The next major version of all the modules below will not be supported on NodeJS versions older than v4. You will need to use babel to compile them yourself.
• Switch to webpack for client side builds
• For most modules it is simply the import and exports that will change and updating the tests

---

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 👍 or 👎 .

[eddyystop]

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?

[bisubus]

Since Node version doesn't impose a constraint, wouldn't it be beneficial for the codebase to get rid of odd uberproto thing in favour of ES6 classes? They are idiomatic and easier to comprehend for both humans and IDEs.

[daffl]

@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.

[bisubus]

@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 proxy doesn't seem to be used in framework code, while the rest of Uberproto functionality already has idiomatic counterparts (guess this wasn't so when the project started).

In my experience, the alternative to Uberproto 'init' feature is to follow the convention that requires to put all initialization logic to _init prototype method that could be extended or overridden in ancestors. And mixins are as simple in ES6 as Object.assign(Foo.prototype, { ... }) - thanks to classes for heavy promotion of prototype methods.

Just wanted to clarify this matter for Buzzard contribution guidelines.

[subodhpareek18]

Should also add UMD builds for client side modules, so that they can be loaded of CDNs like unpkg.com

[daffl]

This has been implemented for all @feathersjs core modules in v3. Ecosystem and other plugins can be rolled out later.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue with a link to this issue for related bugs.