Use graphql-upload inside CommonJS module

[dominik-myszkowski]

Beginning from v.14.0 there was a major change in export of the library contents. Right now there is no easy way to import any part of the library in CommonJS module (require style). It would be nice to have this possibility back again, as this is a library mostly used on server-side, so most of the modules are in CommonJS. Currently the only option is to use dynamic require which is troublesome (async). I am using v.13 because there is no option for me to upgrade.

[jaydenseric]

To be able to use modern npm packages like this one that are in the standard JavaScript module format (ESM), you will need to either use a dynamic import from within a CJS module, or start using ESM in your Node.js projects. Then you can import ESM or CJS dependencies as you please. Many other npm packages are also pure ESM now, as is basically everything published to https://deno.land/x and other modern registries/CDNs.

Moving forward, none of my open source packages will regress from being pure ESM to publishing CJS.

[dominik-myszkowski]

I understand, I was afraid so that CommonJS is no longer supported for this library. Transfering the Node-based project to ESM is out of the question for me, but I will stick to v13. Thanks for the response.

[revero-doug]

common JS is still the de facto standard for interop; I too wish ESM were the standard but it is only in name. Consumers of this library are therefore likely to (dangerously) remain on an old version of this library unless starting a greenfield package and committing to node16/nodenext module format from the start.

[guidiamond]

@revero-doug is there a way to bypass this? I tried changing module to node16 and moduleResolution to node but that didn't seem to work.

[revero-doug]

IMO the best option is to vendor this and add a prepare script that uses rollup to transpile from ESM to cjs, then import that package. Not really practical unless you have a monorepo

On Fri, Jan 6, 2023, 3:24 PM Guilherme Teixeira Batista < @.***> wrote:

@revero-doug https://github.com/revero-doug is there a way to bypass this? I tried changing module to node16 and moduleResolution to node but that didn't seem to work.

— Reply to this email directly, view it on GitHub https://github.com/jaydenseric/graphql-upload/issues/345#issuecomment-1374092463, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2S7EQYNECM7LEJH7LGNRIDWRB5PPANCNFSM6AAAAAARVEL2AE . You are receiving this because you were mentioned.Message ID: @.***>

[adrianescat]

what was the last version with cjs support? at least specify this in the versions list in NPM, please

[rvitaliy]

Consumers of this library are therefore likely to (dangerously) remain on an old version of this library unless starting a greenfield package and committing to node16/nodenext module format from the start.

@revero-doug exactly, unfortunately to upgrade to node16/nodenext is not easy when you have many dependencies, some of them don't support this mode yet...

@jaydenseric i'm understand your position and i respect your job, but please try to re-evaluate this point, with this clear choice, you are putting the users of this library in difficulty.

also try to analize the numbers, the majority of users have remained with the old version as they cannot upgrade. downloads by version see: https://www.npmjs.com/package/graphql-upload?activeTab=versions

[jaydenseric]

I've been in this industry long enough to remember similar arguments people made about supporting old IE; they claimed that it was not an option to abandon the percent of people that for whatever (often "enterprise") reasons were still using it. So then the industry would end up in this negative loop of stagnation because we would bend over backwards to avoid newer web standards and then IE users would continue to have no incentive to upgrade their browser. When an npm package would drop support for old IE, users would complain that this marks the death of the package, yada yada yada. Then a few companies like Google got sick of waiting because the situation was never going to change and they proved that it was in fact, a choice to continue supporting it. Once they normalised dropping support, all the sheep started dropping it as well and the IE market share fell off a cliff once enterprises had a compelling reason to prioritise upgrading their browsers. In the end, the world didn't burn like the naysayers predicted and instead we quickly adapted and the quality of our lives and apps drastically improved. The companies whose websites I dropped support for IE at didn't go bankrupt from loss of customers.

I also remember what it's like to publish a package that gets hardly any installs at first. You have to believe in the quality of what you're doing, and focus on that. In open source, I make the same money if I get millions of installs or hardly any: near $0 (thanks to those of you who do GitHub sponsor me!). I just make the best software I know how; software that I'm excited to use in my own projects in which I'm always pushing technical elegance and best practices. In time people will be deliberately favouring npm packages that are pure ESM; as a package consumer I have already had that habit for some time now in my work projects.

A tip to people frustrated that more and more of their dependencies are pure ESM; trying to convince all these dependencies in GitHub issues to go back to CJS is not going to be a winning strategy. For every one you convince to go back, 3 more will update to be pure ESM. I'm not some renegade package author; the most prolific package authors in the world are also moving everything to pure ESM. It's the ultimate destiny of the JS ecosystem for all packages to be published in the standard JavaScript module format. A winning strategy is to migrate your codebases to ESM, so you can install and consume both CJS and ESM dependencies and eventually forget about CJS.