[v14.0.0] No "main" export in package.json causes import failures

[stewartmcgown]

Package.json does not export a barrel file index, so all existing code must be update to support imports from each unique file inside the package

[jaydenseric]

This is by design, and is documented in the v14 changelog entry under major changes. Deep importing modules with a single export as needed is a vastly more efficient pattern than redundantly loading every module in the package by importing via an index module, just to use one or two of the exports and ignore the rest. This pattern is critical to efficiency in browsers, but also Deno, and even Node.js sees benefits. Projects that bundle will be able to do so with perfect efficiency without needing to do any sort of ESM "tree shaking".

I have been dropping the package main index module anti-pattern from all of my packages; graphql-upload was one of the last ones remaining.

[SueHeir]

Sorry I'm a novice here, what does this mean in terms of fixing the error?

[PiTiLeZarD]

use

import GraphQLUpload from "graphql-upload/GraphQLUpload.js";

instead of the traditional

import { GraphQLUpload } from "graphql-upload";

[jaydenseric]

@SueHeir the module structure has changed in graphql-upload v14, and you need to update the way you import the modules.

You can't import them like this anymore:

import { graphqlUploadExpress } from "graphql-upload";

You need to deep import them like this instead:

import graphqlUploadExpress from "graphql-upload/graphqlUploadExpress.js";

You can see all the available publicly exported modules you can import this way documented here:

https://github.com/jaydenseric/graphql-upload/tree/v14.0.0#exports

If you get confused, you can always just look at the contents of the node_modules/graphql-upload/ directory to see what modules there are:

https://unpkg.com/browse/[email protected]/

[jaydenseric]

Note that when this package updates to pure ESM in a major release coming hopefully within the next few months, the module structure will be the same as v14 except the file extensions will change to .mjs from .js. So we will need to update our imports in projects a second time 😅 It's a pretty easy find and replace tho.

[SueHeir]

Thank you!!

[strangeweb3guy]

@SueHeir the module structure has changed in graphql-upload v14, and you need to update the way you import the modules.

You can't import them like this anymore:

import { graphqlUploadExpress } from "graphql-upload";

You need to deep import them like this instead:

import graphqlUploadExpress from "graphql-upload/graphqlUploadExpress.js";

You can see all the available publicly exported modules you can import this way documented here:

https://github.com/jaydenseric/graphql-upload/tree/v14.0.0#exports

If you get confused, you can always just look at the contents of the node_modules/graphql-upload/ directory to see what modules there are:

https://unpkg.com/browse/[email protected]/

import graphqlUploadExpress from "graphql-upload/graphqlUploadExpress.js";

[jaydenseric]

@kiskesis you might have some sort of build step that is adding .default to your default import values. This is not the right thing to do; you will get this error for a lot of npm package you import from.

[strangeweb3guy]

Hmm, I have a really big count of modules and don't have this error for them.

[strangeweb3guy]

So any ideas on how I can fix that?

[jaydenseric]

@kiskesis within your project, create a demo.mjs file, and in there:

import graphqlUploadExpress from "graphql-upload/graphqlUploadExpress.js";

console.log(graphqlUploadExpress);

Then in terminal within the project directory run node demo.mjs and see that it logs the function just fine. I can't really help you with a faulty build setup; there are a million things that could be misconfigured in your tooling.

[PiTiLeZarD]

Why not both tho? there's no need to be opinionated on this

This is literally the only package that forces me to update the imports for this format. I don't mind it so much but just addressing the "you will get this error for a lot of npm package you import from" which hasn't been my experience

[jaydenseric]

Why not both tho?

Because it's better to only offer the correct, most efficient way. This way people who don't understand the downsides of importing from the main index module vs deep imports, which is most people sadly, "fall into the pit of success". Not publishing an index module also reduces the install size of the package which benefits everyone.

there's no need to be opinionated on this

It's not an opinion, it's a cold hard fact that deep imports are more efficient than importing via index modules with multiple exports. After a decade in this industry I've come to realise this is the single biggest code quality problem in the JavaScript ecosystem that is causing all sorts of profound problems. I can, and will at some point, write a several thousand word article on the topic.

People that (metaphorically) only know how to play checkers might not understand my chess moves here. We are working towards supporting Deno. Once you have HTTP waterfalls during loading of your module graph you start to notice inefficiencies a lot more. Once you cache your modules in the module graph, and you see all sorts of crap you don't need being cached to disk you start to think about ways you can avoid pulling it all in.

For a long time I have known index modules are bad and deep imports are good, but now I've spent over a year doing research and development on this buildless React web application framework for Deno and browsers for which ESM is a critical part:

https://github.com/jaydenseric/ruck

This sort of thing will be common in the future, and when people start to actually use ESM at runtime instead of just build it with their wacky tools they will start to "get" all the things I've been saying.

"you will get this error for a lot of npm package you import from" which hasn't been my experience

As demonstrated by #305 (comment) , I am publishing 100% vanilla Node.js compatible modules. If people's build systems are failing to correctly deal with this 100% valid module, it's a matter of time before they try to use another 100% valid module and get into trouble with that one instead. It's pretty mind boggling that a large code base not once so far has imported a default export from a perfectly vanilla Node.js module yet, but here we are. By chance it can happen it seems.

[jaydenseric]

Browser glitched and submitted my last comment before it was done haha 😅 Editing it to completion now…

[PiTiLeZarD]

"when people start to actually use ESM at runtime instead of just build it with their wacky tools" I'd go with if here. Strong dubious if!

Look again I don't mind so I'm fine with it all, just for the chat here: You're (generic you) not doing libraries to make a point or to bring awareness or to convert people to your current understanding of things (which might be correct but will definitely evolve), but to provide a feature, if you provide all ways to access it and use it, you remove friction, and people enlightened like you (non generic #english) can use it the correct way and think "this guy's a chad", while all the other plebs (like me) can just use the library in a consistent way and move on with our lives lol And we don't have to adapt imports anytime you discover something new you know...

The correct way is not necessarily the most efficient in exclusivity of all others yadi yada I'll stop there, it is just opinions and I understand and agree with why you hold yours, hopefully you wont be too bothered with everyone asking you about it.

Thanks for entertaining this thread, you must be busy, it is appreciated. I'll stop wasting your time!

[strangeweb3guy]

The problem is here, that the most modules in my project will break if I will remove .default rule on build. So for now pain is more then the features from deep import 🫢

@kiskesis you might have some sort of build step that is adding .default to your default import values. This is not the right thing to do; you will get this error for a lot of npm package you import from.

[RemyMachado]

@PiTiLeZarD Is right.
It's been an hour since I started trying to figure out how to use this library.
@jaydenseric At least clarifying it in the readme.md would be great.

Developer experience : 👎

[RemyMachado]

I'm still stuck with:

Compilation error in src/index.ts
[ERROR] 20:01:21 ⨯ Unable to compile TypeScript:
src/index.ts:13:34 - error TS7016: Could not find a declaration file for module 'graphql-upload/graphqlUploadExpress.js'.

[jaydenseric]

@RemyMachado TypeScript compilation errors specific to your project and TypeScript config are not related to the title of this issue. Someone happens to have asked a similar question here:

#282 (comment)

That's a better place to talk about types.

[jaydenseric]

Here is a deeper explanation for some of the recent changes in how I document and publish packages, which will hopefully turn frustration like this to enthusiasm:

• [v14.0.0] No "main" export in package.json causes import failures #305 (comment)

  It's been an hour since I started trying to figure out how to use this library.
  @jaydenseric At least clarifying it in the readme.md would be great.

  Developer experience : 👎

• Latest V15 "Cannot find module koa" #314 (comment)

  I'm so annoyed by this library's import style.
  I'm done.

I care deeply about developer experience (both for package authors, and consumers) and have demonstrably dedicated my life to improving the JavaScript ecosystem to help people build more amazing things, easier. For some other packages when you have frustrations it might be because the author was careless. For my packages, there are almost always very special reasons for everything that might not be obvious unless we get a coffee together and talk for half an hour.

Firstly, the readme clearly documents what modules are publicly exported, what format they are in, what there file names are, and even link to the package.json file so you can see the package exports yourself:

graphql-upload/package.json

Lines 39 to 46 in cd9e4f1

	"exports": {
	"./GraphQLUpload.js": "./GraphQLUpload.js",
	"./graphqlUploadExpress.js": "./graphqlUploadExpress.js",
	"./graphqlUploadKoa.js": "./graphqlUploadKoa.js",
	"./package.json": "./package.json",
	"./processRequest.js": "./processRequest.js",
	"./Upload.js": "./Upload.js"
	},

The way this works is not some weird exotic thing I am doing to be cruel to users; this is the basic way modern Node.js packages export modules and how you can import them. Unfortunately, people have been abstracted from their medium by very complicated tools that work in non-standard ways for so long to the point that the way vanilla Node.js packages and modules works is a mystery to them, or worse, when they do come across things done properly they think it must be somehow wrong!

The burden is not on every package published to npm to teach users in the readme about how to use Node.js and npm; it's expected users have that base knowledge. Over time people will learn the right way to do things, legacy tooling that confuses people will be left behind, and all these problems will recede.

I am moving away from documenting in readmes actual code examples of what import statements to dumbly copy-paste, because many of these packages are now (or will be in the near future) used equally by Node.js, Deno, and browsers and the imports you should use look totally different depending on what your project is like.

For example, (picking a package that supports Node.js/Deno/browsers) if we were to document doing it this way:

import Cache from "graphql-react/Cache.mjs";

That would be incorrect for Deno or browser users that need to do it differently:

import Cache from "https://unpkg.com/[email protected]/Cache.mjs";

But, depending on their projects for a lot of reasons they might need to do it any one of these other ways instead:

import Cache from "https://esm.sh/[email protected]/Cache.mjs";

import Cache from "https://esm.sh/v82/[email protected]/es2021/Cache.mjs.js";

import Cache from "https://cdn.jsdelivr.net/npm/[email protected]/Cache.mjs";

import Cache from "https://ga.jspm.io/npm:[email protected]/Cache.mjs";

Not only do a growing number of CDN's exist, but you might use special query string parameters that can enable or disable minification depending if you are doing development or production work, etc.

Note that most Deno and browser projects will be using import maps, so that further complicates things because users can map their imports to allow them to do this in their project code if they wanted:

import Cache from "cache";

I don't want to show a bias to a particular CDN or funnel users into a setup not appropriate for their project, and it's not feasible for me to show import code examples in the readme for every possible way. If we hardcode a particular CDN into docs, what happens if that CDN one day is deprecated or compromised? We don't want to get the whole ecosystem addicted to one CDN just because it's what all the readmes show and people get used to it; that stifles the ability for innovative new CDNs to arise and compete.

The best we can do is document what modules are published in the package, and users need to have a basic competency about their chosen package manager, CDN, or runtime to know how to access that.

Regarding my decision to remove the generated API docs from my readmes, that is because the existing tools (i.e. jsdoc-md) that I spent many months inventing and evolving are no longer appropriate for TypeScript flavour of JSDoc comments, which is the most reliable way to have type safety. I go to great lengths to have rich JSDoc descriptions for everything that displays as intellisense in your editor with clickable links to relevant types or exports. For many people, this developer experience is superior to looking up API documentation in a readme.

The future of API documentation is web apps that scan the published modules and dynamically present docs for them with rich UI (not limited to what static markdown can do). Not building API docs simplifies dev dependencies a lot, and it prevents a lot of trouble where your source code changes but the API docs were not regenerated (for example someone does a PR, then the GitHub Actions CI for it errors that the docs are now out of date, and then they have to learn to use the npm run jsdoc script after making changes). As the dynamic doc sites get better, so does the docs for every version of the package. If the docs were hardcoded in the readme and published, you would be stuck with whatever quality they were for those versions forever.

Unfortunately it's not very mature yet, because they don't (yet) handle import maps and they fail to detect certain parts of the API, but they are definitely the future we should align to and there is active work being done to improve these tools.

Here is an example link, that doesn't do a very good job yet:

https://doc.deno.land/https://unpkg.com/[email protected]/Cache.mjs

Here is another example that is more successful:

https://doc.deno.land/https://deno.land/[email protected]/datetime/mod.ts

Now remember back to how code examples for imports have been removed from the JSDoc; if they were still there, the docs these web apps generate would look pretty annoying because they would automatically show a generated import code example, as well as the manually written JSDoc example. Duplicated content for a reader.

Another problem is that having JSDoc code examples for imports in every module considerably bloats the byte size of these modules when you are importing them without a build step (e.g. minification) that would strip them out. They also can be annoying in situations like editor intellisense, because you clearly already know how to import it if you are looking at it!

The reason you might be more surprised by the way I do things with my packages more often than others, is because I'm one of the few package authors that is genuinely tackling the challenge of universal JavaScript modules that work in Node.js, Deno, and browsers, with type safety, buildless. When our ecosystem is there our collective productivity and satisfaction will be off the charts.

[RemyMachado]

Thank you for the clarification. As already said above, even if it's a more efficient import, it's not usual. I would say you are ahead of your time and I don't consider myself a beginner, but understanding the way imports have worked, work and will work isn't interesting to me. I would rather go with a simple standard import and get my work done #KISS.

Now, if it's well documented and as simple as changing the line of import from { y } from x to from x/y it's not a big deal, but having to change my configuration (i.e. TypeScript) for this single package to work with the dozens of others, it's too much.

Giving us the choice about how we import things would be a better move.

[wilo-dev]

Greetings community I have this error :

I did what they recommend when exporting the module but the error still persists:

It should be noted that I am using JavaScript with node v16.13.1 :

[jaydenseric]

@willian593 assuming the imports have been updated correctly, the next thing to solve is your TypeScript config and maybe version. You can see some tips here:

#282 (comment)

[ziaenezhad]

@jaydenseric does it worth wasting such a lot of developers' time?
Just to help machines to save only a little bit of memory and CPU?

[forrestwilkins]

What version of graphql-upload lets us import GraphQLUpload or others normally?

Edit: I was able to get it working with 13.0.0.

[xinghul]

let's be honest here, this package is used on the server-side, and size matters less compared to frontend packages, what would affect the performance of the server would usually not be the amount of modules or size on disk, but the actual activities that those modules are performing upon receiving a request.

With that being said, does it really worth wasting people's time over those optimizations? my webpack config is already complex enough, and I wouldn't add another hack just to bypass the import issue.

[aamancio]

Maybe you should rewrite the package in Rust for more CPU efficiency because we all know that we all used Express.js.

[CemYil03]

This [ edit: maybe calling it stupid was a bit harsh, sorry for that but this was an emotional day :) ] repo has cost me half the day until I took the time now to read this entire discussion. Why don't you split the repo, one for Deno people and one for regular JS- / TS-Developers?

I wanted to include this in a NestJS-Apollo project. It does not help that googling for graphql file upload always results in old tutorials which use the straight forward import syntax.

I would not complain if simply switching out the import syntax would be enough, but having to change tsconfigs and stuff simply is too much.

What this lead me to do is, that I have version 13 as a dependency now. And to be honest I think that many people feel forced to now work with a older version, even if aside from import syntax, totally different things have improved, but are sadly not usable :(

I would not recommend this package to friend, but I would probably tell him that I do sadly not know of an alternative.
If there was one I guess the npm download numbers for this one would break down immediately.

EDIT / ADDITION:
Now thinking about it, I tried to include this library a few months ago and ran into problems. Due to time restrictions I even created a classic REST-Form-Data endpoint, just for my file uploads.

[3axap4eHko]

yarn add graphql-upload@13

[jaydenseric]

I just published a detailed article on optimal JavaScript module design:

https://jaydenseric.com/blog/optimal-javascript-module-design

It explains 6 important reasons why index modules are an anti-pattern, and although some have already been discussed here in this GitHub issue, the article holds the important details in one place and is a fast way to get up to speed.

[PiTiLeZarD]

Nobody is saying you're not right about this, what people are trying to tell you is that there is the way you consider better/right/optimised/whatever, and there are other ways, and while making a library, it would be great to include all ways so people get to use the feature without engaging in the elitism of the language or changing everything they already have.

I will however read the article, thanks for writing it!

[Edit after reading it]: This is all moot if you do use a packager, webpack, parcel, bun etc... your only argument against these is build time? people use these bundlers for many different reasons, tree shaking is just one of them. Build time is slower? If you're into over optimising this, you can still deep import everything, nobody stops you! I have countless apps being built, they're all built under 3mn max and that includes making and pushing docker images. There is many steps I could take to make this faster and I will, maybe, but getting rid of the bundler is not even in question. Again: not everyone codes raw for deno, you do, and that's great, but I guess you're making this library for other people now are you? Are you?

[stewartmcgown]

Patch to fix this bug:

diff --git a/node_modules/graphql-upload/index.js b/node_modules/graphql-upload/index.js
new file mode 100644
index 0000000..8e5e4e0
--- /dev/null
+++ b/node_modules/graphql-upload/index.js
@@ -0,0 +1,15 @@
+import GraphQLUpload from "./GraphQLUpload.js",
+import graphqlUploadExpress from "./graphqlUploadExpress.js",
+import graphqlUploadKoa from "./graphqlUploadKoa.js",
+import processRequest from "./processRequest.js",
+import Upload from "./Upload.js"
+
+
+export {
+    GraphQLUpload,
+    Upload,
+    graphqlUploadExpress,
+    graphqlUploadKoa,
+    processRequest,
+    Upload
+}
\ No newline at end of file
diff --git a/node_modules/graphql-upload/package.json b/node_modules/graphql-upload/package.json
index 91fc77e..bcc9fe7 100644
--- a/node_modules/graphql-upload/package.json
+++ b/node_modules/graphql-upload/package.json
@@ -8,6 +8,7 @@
     "email": "[email protected]",
     "url": "https://jaydenseric.com"
   },
+  "main": "index",
   "repository": "github:jaydenseric/graphql-upload",
   "homepage": "https://github.com/jaydenseric/graphql-upload#readme",
   "bugs": "https://github.com/jaydenseric/graphql-upload/issues",
@@ -26,24 +27,8 @@
     "esm",
     "mjs"
   ],
-  "files": [
-    "GRAPHQL_MULTIPART_REQUEST_SPEC_URL.js",
-    "GraphQLUpload.js",
-    "graphqlUploadExpress.js",
-    "graphqlUploadKoa.js",
-    "ignoreStream.js",
-    "processRequest.js",
-    "Upload.js"
-  ],
+ 
   "sideEffects": false,
-  "exports": {
-    "./GraphQLUpload.js": "./GraphQLUpload.js",
-    "./graphqlUploadExpress.js": "./graphqlUploadExpress.js",
-    "./graphqlUploadKoa.js": "./graphqlUploadKoa.js",
-    "./package.json": "./package.json",
-    "./processRequest.js": "./processRequest.js",
-    "./Upload.js": "./Upload.js"
-  },
   "engines": {
     "node": "^14.17.0 || ^16.0.0 || >= 18.0.0"
   },

Haven't actually tested this so LMK if it works. patch-package doesn't seem to work for me inside a docker container.

[IlmariKu]

I think it's pretty obvious that because of the decision made by this package owner about the imports, the vast majority of developers simply won't update their graphql-upload package.

From NPM-registry:

Version	Downloads (Last 7 Days)
16.0.0	3,512
15.0.2	14,902
14.0.0	665
13.0.0	80,678
12.0.0	79,745
11.0.0	233,156

[jaydenseric]

I’m not motivated by vanity metrics like install counts, or money (I get practically none from this open source stuff; thank you to those of you who sponsor me). I’m building the best software I know how, for people that also value the same. I’m confident my technical choices are on the right side of history and in time install counts will rise.

I’ve been in this industry long enough to remember what a brave leap of faith it was to get off of jQuery, or to drop support for IE6, or IE8, or any number of things big corps would gaslight you into believing are important. They say the best tools are those you build for yourself. Well, I don’t want CJS anywhere in my module graphs. I want to be able to use software like this in Deno. I want my packages to work in browsers with import maps out of the box. None of this has come out of the blue, there has been years of warning. I’m not some renegade out to disrupt everything. Other package authors with millions, and even billions of install counts are also moving to pure ESM. Because It's fundamentally a necessary change.

I was one of the very first authors to experiment with and publish support for dual ESM/CJS packages. I've been working with it in production since the --experimental-modules days. After years of experience, I can say with confidence it's a bad idea. Pure ESM with optimal module design is the way forwards.

Regarding some of the comments I haven't responded to challenging my optimal JavaScript module design choices; I didn't respond not because I have no response but because I've already explained these concepts multiple times. I spent 4 days of effort over a weekend and workdays to write the article explaining it, and the comments left here afterwards are clearly missing major points that were explained.

Most corporations or indie package authors would have locked these issues long ago, but I'm a free speech absolutist. Go ahead, voice your dissatisfaction or dissent. But please be aware that the consequences of your speech may make me feel pretty frustrated and sad, and I don't always have the time or energy to respond.

[jaydenseric]

I also want to point out how toxic the behaviour has been in this conversation. @PiTiLeZarD kindly helped people out by explaining how to migrate imports, without necessarily saying they agreed with the change, and you gave him 12 thumbs down for the kindness:

[RemyMachado]

Yes, this thread is getting toxic, but not about the thumbs down. They are great to show disagreement.
I think it's pretty clear that the users of this library aren't satisfied with the way imports are working here.

@jaydenseric With all this feedback, are you reconsidering to put back previous import style? (maybe keep the two styles if it's possible to meet both ends).

[stewartmcgown]

Most corporations or indie package authors would have locked these issues long ago, but I'm a free speech absolutist. Go ahead, voice your dissatisfaction or dissent. But please be aware that the consequences of your speech may make me feel pretty frustrated and sad, and I don't always have the time or energy to respond.

You're absolutely right Jayden. I opened this issue from a purely technical standpoint and it's become a mess. No need for this barrage of people weighing in and calling this repo "stupid". I commented my diff that I'm using above, which will solve the "problem" for most people and you can all move on with your days without giving the maintainer grief.

Interesting to note that not a single person has created a PR for this issue.

Thanks for the repo mate. Super useful project for the GQL community 😊

[CemYil03]

In my understanding the biggest problem is when people are trying to use graphql-upload in combination with TypeScript. See #325. Maybe it would help to provide an example setup. For me personally NestJS would be ideal, but I think I am not the only one working in this context.

1. Setting up a base project: https://docs.nestjs.com
   npm i -g @nestjs/cli
nest new graphql-upload-example

2. Including GraphQL / Apollo: https://docs.nestjs.com/graphql/quick-start
   npm i @nestjs/graphql @nestjs/apollo graphql apollo-server-express

3. Generate a class called AppResolver
nest g r app

4. Include the package dependency
   npm i graphql-upload
npm i -D @types/graphql-upload

5. Implement one mutation where you can upload a file

6. Fixing the default NestJS-TypeScript-configuration or whatever necessary

With such a demo repo with commits after each step I would very gladly include the latest version of this package in my production code.

[koresar]

Hi all.
I will keep my fork of graph-upload as CJS compatible forever.
You'll never have to deal with module type incompatibility.

[jaydenseric]

@koresar

I will keep my fork of graph-upload as CJS compatible forever.

That won't be possible with graphql v17, which will be pure ESM:

https://github.com/graphql/graphql-js/releases/tag/v17.0.0-alpha.1

You won't be able to require it here:

https://github.com/flash-oss/graphql-upload-minimal/blob/40e1c69f30a11556b2c6e657ed9656542cfbd1ff/public/GraphQLUpload.js#L1

[koresar]

@jaydenseric I know. I'm fine with it. People (or us) would maintain a fork of graphql-js.

Also, we've already jumped off all the Sindre's modules. node-fetch will be replaced with Node built-in fetch. etc. We are ready for the world to move to ESM.

We have large (huge!) Node projects. We won't be able to convert it to ESM ever. For us it's simpler to maintain forks of popular repos than to migrate to ESM. In other words - not migrating to ESM is financially cheaper.

Btw, the graphql-upload-minimal still runs is Node 8. Some people need it. And I feel them.

[andreasciamanna]

I stumbled here trying to find a solution.

Mine is a NestJS project with all packages to the most recent version, as far as I can see.

If understand it right, I must use import graphqlUploadExpress from 'graphql-upload/graphqlUploadExpress.mjs';, which I did.

However, the new error is this:

main.js:8
const graphqlUploadExpress_mjs_1 = __importDefault(require("graphql-upload/graphqlUploadExpress.mjs"));
                                                   ^
Error [ERR_REQUIRE_ESM]: require() of ES Module 
/.../graphql/node_modules/graphql-upload/graphqlUploadExpress.mjs not supported.
Instead change the require of /.../graphql/node_modules/graphql-upload/graphqlUploadExpress.mjs to a dynamic import() which is available in all CommonJS modules.
    at Object.<anonymous> (/.../graphql/dist/src/main.js:8:52)

I can't switch the type of the project to "module" without breaking everything else.

I've tried to find some hint here, but the thread became a bit too noisy, and it's hard to find how I can solve my problem (assuming there is a solution).

Googling isn't helping either, as I get the most obvious answers (e.g. "set "type": "module",), which, again, do not help in my case.

Any hint would be appreciated.

[ajolsavsky]

RIP to all bootcamp students (like myself) who are required to use Apollo and CommonJS and find a package like this which holds the monopoly on upload functionality. 12 hours later just downgraded my package to 13 thanks to this thread!

Creator, could you please just include a single line in your documentation that clearly states that from v 13 on ES6 is required so that students/devs with geriatric code like myself can just get on with their lives? I'm sure the industry will catch up to your genius someday soon, but meanwhile there are still legacy apps around that just "can't even." Thank you kindly.

[PiTiLeZarD]

Not sure if that changes anyone's mind but even the folks at Deno understand that you kinda have to be compatible with all, as otherwise you specialise yourself out of existence. From their blog:

Maybe not too surprisingly, Deno users have been a bit split on the best level of compatibility with Node. A large number of you have called out how refreshing it is to get away from all the pain of Node – from the antiquated and non-standard APIs to the odd module loading heuristics. We hear you, and these were some of the main reasons that our team created Deno in the first place.

Still, a fair number of you just want an easier way to interoperate with JavaScript written for Node and distributed as an npm package. We want Deno to be accessible and solve people's problems, and so we've been working on some updates that will allow Deno to easily import npm packages and make 80-90% of npm packages work in Deno within the next three months.

[koresar]

@ajolsavsky there is no monopoly. See the module named:

graphql-upload-minimal

[martialanouman]

Simply said, if you're not ready for the enlightenment, just stick with the @13 version 😄 or use graphql-upload-minimal package

[tommaso-merlini]

yarn add graphql-upload@13

love you

[prasanna-colan]

yarn add graphql-upload@13

It works.