jaydenseric
commented
1 year ago I am greatful that you spend your time to develop this library and that you made it available for free.
Thanks ❤️
But as an author of such a popular widely used library you are also responsible to main the project in a way that people can rely on it. The decisions to migrate to ESM modules without a working backup option is pretty narrow minded.
The situation is more nuanced than you think. For example, graphql v17 is pure ESM:
https://github.com/graphql/graphql-js/releases/tag/v17.0.0-alpha.1
I have a responsibility to my users that graphql-upload is compatible with the latest version of graphql. I can't support both CJS users and also graphql v17 at the same time. So, what is your "open minded" suggestion to me to deal with that? Bullying the graphql project on behalf of for-profit mega corporations that don't want to invest money cleaning up CJS technical debt in legacy codebases, to try to pressure graphql to go back on their decision to use the web standard format for JavaScript would not be what I consider "open minded". It would not make the ecosystem better because we actually need graphql in ESM format to be able to use it in browsers, Deno, etc. Suggesting they ship an ESM and CJS version at the same time causes huge technical problems in the ecosystem due to the dual package hazard.
The graphql-upload dependency fs-capacitor is pure ESM these days. What is your "open minded" solution to that? Bullying them to revert back to CJS? Forking them?
Enterprises need to realise that they have no choice but to adopt the standard ESM format for runtime code, or else they will be locked out of more and more packages on npm and Deno Land. It's common sense.
We use nestjs and I know about the ESM import issue there, but nestjs is a huge framework and bigger companies simply won't rely on home made frameworks. Their rather set in proven technology stacks.
Let's ponder the mental backflips going on here. You acknowledge the Nest.js project has debilitating bugs regarding ESM, which is preventing projects from using some of the most useful packages on npm. Yet you call this a "proven technology stack"! More like, proven to be not fit for purpose.
I've worked on GraphQL projects for various companies over the years since it came into existence, and none of those teams used Nest.js. Honestly, my first impression is that it's something for noobs; it's stitches together a bunch of things into a framework me and all my senior coding friends would rather have control over setting up ourselves. For the very reason you are discovering; you run into bugs because of their opinions or poor maintenance and you can't do much to fix the issues yourself. It's never crossed my mind that I would want a framework to setup a GraphQL API.
In my opinion you should clearly focus on compatibility otherwise the effort you have put in here will be in vain.
I AM focusing on compatibility, by using the standard format for JavaScript (ESM). I'm working towards supporting runtimes other than Node.js.
For free, I publish software that is as technically excellent as I know how, because I want to use the best in my own projects, and I want other people who value that to have an easy to use best-practice solution. I want to set an example for positive change in the ecosystem; someone has to go first or we all fester and stagnate and never climb out of technical debt. This frustration of adopting ESM is a once in a lifetime hardship; there is not going to be another format to migrate to for the foreseeable future.
My work is not "in vain" if legacy enterprise CJS codebases don't update right away to my latest ESM packages. I am absolutely sure that a trickle of installs will eventually become a torrent; the growth curve won't be linear. Anyway, I get paid the same if 1 person installs it or 100 million: $0.
Pressuring me about the ESM move is just shooting the messenger; you will find yourself raising issues like this in more and more repos. Eventually every maintained package on npm will be in pure ESM format.
Cristiandi
tugascript
I am greatful that you spend your time to develop this library and that you made it available for free.
But as an author of such a popular widely used library you are also responsible to main the project in a way that people can rely on it. The decisions to migrate to ESM modules without a working backup option is pretty narrow minded.
We use nestjs and I know about the ESM import issue there, but nestjs is a huge framework and bigger companies simply won't rely on home made frameworks. Their rather set in proven technology stacks.
As of now this library is unusable with nestjs and we have to use graphql-upload-minimal.
In my opinion you should clearly focus on compatibility otherwise the effort you have put in here will be in vain.