Comments (4)
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.
from graphql-upload.
Thank you for the opinion.
from graphql-upload.
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.
from graphql-upload.
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.
from graphql-upload.
Related Issues (20)
- Unexpected end of form at Multipart._final HOT 4
- NPM package dicer DoS vulnerability HOT 2
- How can I upload file on Next.js HOT 1
- Apollo Server v4 with Lambda HOT 1
- ERROR [ExceptionsHandler] Multipart: Boundary not found - Digital Ocean - AppPlatform HOT 1
- FileUpload - where is fileName, mimetype and createReadStream ? HOT 8
- Error [ERR_REQUIRE_ESM]: require() of ES Module not supported HOT 8
- Hard to find FileUpload interface. HOT 1
- Error: No "exports" main defined in /Volumes/Personal/code-work/node-projects/office/pf-node-backend/node_modules/graphql-upload/package.json HOT 1
- Why misorder of operations and map will cause error thrown? HOT 3
- export graphqlUploadExpress HOT 4
- Invalid object path for the 'map' multipart field entry key '0' array index '0' HOT 1
- in my mutation i have two arguments which have Upload type and both return null HOT 2
- ERR_PACKAGE_PATH_NOT_EXPORTED HOT 1
- Error: Expected undefined to be a GraphQL nullable type.
- Apollo Server v4 issue - BadRequestError: POST body missing, invalid Content-Type, or JSON object has no keys. HOT 2
- Graphql-upload not working for Type-Graphql based project But old version of graphql-upload (.js) version works HOT 1
- Cannot find type definition file for 'fs-capacitor'. HOT 1
- Graphql File Upload NestJS issue HOT 3
- upload multiple images has error HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from graphql-upload.