Remove Babel from production dependencies

[koresar]

Thanks for the great module!

Not sure if intentional, but package.json references the "@babel/runtime": "^7.0.0-beta.39",.
My Lambda (or microservice) definitely do not want that big thing in the memory on on the disk.

Is it removable?

[jaydenseric]

The whole runtime does not load and run, only the minimal helpers necessary for our level of node support (via @babel/preset-env) are imported. The helpers can be shared across dependencies instead of being repeatedly inlined in each package.

[koresar]

I see.

Still, I wonder why downloading those megabytes is that necessary. Sounds like a small module with just a 100 lines of code, but it brings too much with it.

.mjs is not yet LTS. Thus, majority of people would be using your module from node 6 and 8. All will now depend on huge @babel/runtime module (1.2MB). I know that new cool import/export syntax is awesome. But, for compatibility sake, should this module depend on busboy and object-path only?

Usually, small modules try to depend on as less as possible. That's a common practice.
I can help with a PR if any.

[jaydenseric]

The runtime dependency has nothing to do with .mjs or ESM.

Only two imports in the dist files depend on the runtime dep:

The first _asyncToGenerator import is because the koa middleware uses async/await. This could be refactored to just return a promise. The second core-js/modules/es7.object.entries import is because Object.entries() is used here. It could be refactored too.

A downside to making changes like this is that when we want to increase Node.js support to something more recent, we will not easily know what can now be refactored to modern syntax.

The best way to maintain a fleet of packages is to use current ES in the source and set up transpilation with @babel/preset-env, defining the level of support using package.json engines.node and browserslist. Simply adjust these values for the dist files to magically transpile with the minimum required runtimes/polyfills, etc.

While we could manually audit builds and work backwards to remove the need for the runtime dep, this is risky because updating deps, merging PRs, adding features, etc. would require fresh audits.

huge @babel/runtime module (1.2MB)

This is the first I have heard of our install size being a practical issue; are you sure it's a problem? I just installed the dependencies for a minimal server (npm install apollo-server-express express graphql) and the folder is over 7 MB:

Add in a few other dependencies typically used in resolvers (moment, mongodb, etc.) and you can expect many more MB. Proportionally our dependencies are modest, and as more people update to babel@7 lots of packages will be sharing the runtime dep so the overhead due to using it here will be zero.

AWS Lambda is horrifically behind the times, by the looks of it even their own SDK is outdated. Ideally they will update their environment to a recent Node.js version sometime soon, then we could move Node.js support right up to v7.6+ or even greater. Then the chances of needing the runtime are small enough to justify removing it from dependencies and transpilation.

[koresar]

Thank you for the opinion.