[RFC] Bundle size optimization

[petermikitsh]

As discussed in #1028, all @feathersjs namespaced modules (with the exception of @feathersjs/client) ship as ES modules, and it is the responsibility of users consuming these modules to compile them as necessary.

Surprisingly, @feathersjs/* packages are my 4th largest dependency.

Since we are already shipping ES modules, why not take advantage of language features such as import/export syntax, and then setting {sideEffects: false} in package.json files so you can get tree shaking?

One of the biggest files that is imported in the client is commons/lib/utils.js. This file is just a group of utility functions. It's the type of file that could potentially have a smaller footprint with tree-shaking.

Speaking to my particular use case, here is every file I import from the @feathersjs namespace sorted by filesize:

Filename	Size
@feathersjs/authentication-client/lib/passport.js	10 KiB
@feathersjs/feathers/node_modules/@feathersjs/commons/lib/utils.js	8 KiB
@feathersjs/feathers/lib/hooks/index.js	7 KiB
@feathersjs/errors/lib/index.js	7 KiB
@feathersjs/feathers/node_modules/@feathersjs/commons/lib/hooks.js	6 KiB
@feathersjs/transport-commons/lib/client.js	5 KiB
@feathersjs/feathers/lib/application.js	4 KiB
@feathersjs/feathers/node_modules/@feathersjs/commons/lib/filter-query.js	3 KiB
@feathersjs/feathers/lib/events.js	3 KiB
@feathersjs/authentication-client/lib/index.js	1468 bytes
@feathersjs/authentication-client/lib/utils.js	1310 bytes
@feathersjs/authentication-client/lib/hooks/populate-entity.js	1174 bytes
@feathersjs/feathers/lib/hooks/base.js	1042 bytes
@feathersjs/socketio-client/lib/index.js	1019 bytes
@feathersjs/authentication-client/lib/hooks/populate-header.js	797 bytes
@feathersjs/feathers/lib/index.js	770 bytes
@feathersjs/authentication-client/lib/hooks/populate-access-token.js	381 bytes
@feathersjs/authentication-client/lib/hooks/index.js	318 bytes
@feathersjs/feathers/node_modules/@feathersjs/commons/lib/commons.js	202 bytes
@feathersjs/transport-commons/client.js	41 bytes
@feathersjs/feathers/lib/version.js	25 bytes

[daffl]

Feathers only uses language features that are natively supported by Node 6 or later. Unfortunately ES modules are not part of ES6 and not supported by Node yet. Size wise, the authentication client will likely be much smaller in the next version and the sorting utility could manually be put somewhere else. It is indeed not needed in Feathers core.

[petermikitsh]

The end goal is bundle size optimization, the imports were merely a suggestion of one possible strategy for achieving it. Optimization should be possible with the constraint of Node 6 (or later) functionality.

[petermikitsh]

By the way -- you could still ship a transpiled build that supports Node v6 if you wanted to take advantage of newer JS features.

[daffl]

I think a lot can be gained here from the client in the next version of authentication, moving the sorting mechanism somewhere else and #932.

The reasons for dropping Babel compilation (it was used in pre Buzzard) have been outlined in #608 although some (like installing directly from GitHub) do not apply to the monorepo anymore.

I'm not opposed to adding a compilation step again but in that case, migrating the codebase to TypeScript (#565) - which is more well-defined than most non-standard ES features - would make more sense to me.