Why the move away from npm registry?

JSin commented 2 years ago

I noticed from this ed18acd63d7a5cd31527a36a9af54542cdfcfd30 that you moved away from publishing to the npm registry and recommend people download using tarballs on the CDN. Why did you move away? The npm registry is an extremely common way to download packages.

SheetJSDev commented 2 years ago

The package on the npm registry is surprisingly popular (one of the top-500 by dependents). npm invalidated the old publish token and is forcing 2FA on the publishing account.

Due to ongoing legal matters between SheetJS LLC and npm, Inc. (which will not be discussed here), it did not make sense to continue using the public npm registry for distribution.

With GitHub (the owner of NPM) sunsetting the git.io domain with only 4 days notice, we are reminded of the ephemerality of the Internet and the inherent risks of relying on platforms.

claylevering commented 2 years ago

we are reminded of the ephemerality of the Internet and the inherent risks of relying on platforms

https://sheetjs.com/careers

familiar with the tumult of open source and remote collaboration

not prepared to collaborate with the JavaScript and data communities

Top 500 NPM package list, 1.26 million downloads a week, over 3000 dependent packages and not even a mention in the README regarding the fact ongoing development for this package won't exist any longer in the single largest JS library platform on the planet (after 8 years).

🤔

ljharb commented 2 years ago

Mandatory 2FA should be a noop, as a responsible maintainer would already have it enabled.

npm publish tokens remain exempt from 2FA, so i'm not clear on why that would be an obstacle.

jonkoops commented 2 years ago

Yeah, 2FA should be a no brainer. An tokens are indeed except if specified.

judehunter commented 2 years ago

This is bizarre

lynnntropy commented 2 years ago

Full disclosure, I happened upon this issue by chance and am not a SheetJS user, but this is... really strange.

The package on the npm registry is surprisingly popular (one of the top-500 by dependents). npm invalidated the old publish token and is forcing 2FA on the publishing account.

What possible justification could you have for taking issue with npm's 2FA requirement for maintainers of popular packages?

With GitHub (the owner of NPM) sunsetting the git.io domain with only 4 days notice, we are reminded of the ephemerality of the Internet and the inherent risks of relying on platforms.

I don't see how this is a reason for silently dropping support for npm. If anything, from the perspective of your users it's an argument for the opposite, because npm is statistically way more likely to exist 5 years from now than your personal CDN.

Maintainers of OSS projects don't owe people anything, of course, but all I can say is you shouldn't be surprised when people (including your paying customers) look at this whole thing and decide to either fork the project or switch to a competing library not maintained by someone who makes decisions like this.

rozzzly commented 2 years ago

I'm imagining a conversation somewhere along the lines of:

phone rings. Oh crap it's the CTO! what does he want?!?

Hey, I just got an email saying that our MPM account didn't have 2FA enabled. I think that's like really important, right? Why didn't you have it enabled?

Moment of terror. My predecessor setup the account... I never thought to check if 2FA was enabled! But I probably shouldn't say that to the CTO because I definitely should have noticed. Um what to say.. uh.. um. come on think! think AHA I got it!

Really sir? That is uh very concerning. They must of uh like um deleted our settings.

Deleted our settings?! That's outrageous! They can't do that! Those are OUR settings. You know what, just go ahead and only post it on our site from now on.

Post it on our site? Like a CDN? I mean it was probably just a glitch, I'll uh I'll just reset the security settings. Problem solved.

No. I doubt these MPM guys will be around a lot longer anyways. You will post it on our site only from now on, am I understood?

uh.. yes...

Good work, I'm going to go call the lawyers about this.

CTO hangs up. Oh God what did I just do?!

Directory commented 2 years ago

JavaScript hippies back at it again with the tri weekly cdn outages

jameshilliard commented 2 years ago

Not sure why one would want to use the sheetjs CDN for npm installs instead of just doing something like this(github based install):

npm install SheetJS/sheetjs#semver:^0.18.6

bluepuma77 commented 2 years ago

npm package xlsx has 1.4 million weekly (!) downloads of outdated version 0.18.5.

@SheetJSDev It would be great if you could add a notice to the npm readme.

A warning during "npm install xlsx" would also be great, mentioning alternative install methods.

schw4rzlicht commented 2 years ago

Hilarious.

TruffeCendree commented 1 year ago

@SheetJSDev

First, thanks for your amazing work on this library.

Because of security concerns, I prefer relying on npm up-to-date package with proper version management, immutable release binaries and npm audit facilities. I'm sure your users would appreciate an update of the well-known npm registry.

If the issue is 2FA related, other popular packages solved the issue. Without you explaining the other reasons, it is hard to understand the withdraw.

Have a nice day.

MartinDevillers commented 1 year ago

This has got to be the most bizarre OSS move I've seen since 2016 when an angry developer unpublished all his 250 npm packages and broke builds all over the planet.

There are over two million weekly downloads on npm pulling in an outdated version of this library. This number is growing meaning an increasing number of developers are installing the wrong version.
There are no warnings whatsoever to let developers know they're using the wrong mechanism to pull in this dependency. The brief mention on the fourth paragraph in the README is not sufficient. This needs to be a bright flashing red banner at the very top. The NPM package entry should be updated to reflect this is no longer the latest version and to encourage developers to move over to the CDN.
As per the official documentation: "For general stability, "vendoring" modules is the recommended approach:". As in, the recommended approach is for me to manually download a tarball of the latest release and then add it to my GIT repository. This feels like going two decades back in time before package managers came into existence. I understand/appreciate this will protect me from supply chain attacks and shoddy internet connections -- but come on. Literally every other package I install will still be coming from the public registry. And if I want to protect myself from supply chain attacks or availability problems of the registry then there are other solutions out there like running a private registry as a personal clone or simply adding node_modules to GIT.
To summarize, the motivation for this change is flimsy. I understand it's either "I don't want to use MFA" or "I'm in some legal trouble with npm". I don't get it.

Whatever your beef with npm is, please work it out and move on. Don't let it ruin what is otherwise an exceptionally well-designed and well-maintained project.

nrutman commented 1 year ago

Just wanted to second the motion for a big update to the README and a warning when installing from the public registry. This is very abnormal and I (like many others, most likely) did not realize I was running on an old version of this package.

marracuene commented 1 year ago

Came across this due to this recently-announced vulnerability (our build pipeline is configured to fail if we have deps containing vulns of a certain level): https://github.com/advisories/GHSA-4r6h-8v6p-xvw6

XLSX CE is a great resource, and free, and indeed it is the maintainer's right to host versions wherever they choose. However, the stated reason for moving it away from NPM "I don't want to use MFA" does lead us to question whether this is a safe package to continue using - given that it will always be rather vulnerable to supply-chain attacks. We had implemented some small POC features with it, and were about to add more.

UPDATE 14/06/23: we ended up switching to https://www.npmjs.com/package/export-from-json - a much smaller feature set than sheetjs, but does just what we need, small and no deps.

srl295 commented 1 year ago

Why the move away from GitHub?

YogliB commented 1 year ago

@marracuene how flexible is it? I had to do some complex Excel manipulations at work and SheetJS was the only package I found that's relatively maintained and can do complicated stuff...

marracuene commented 1 year ago

@marracuene how flexible is it? I had to do some complex Excel manipulations at work and SheetJS was the only package I found that's relatively maintained and can do complicated stuff...

@YogliB I suspect it would not handle your use case. In our use case we already have, in-memory, an array of Objects that represent the information to be exported via Excel. All the work to prepare this information has already been done.

The only additional work done at time of export (and which the new package allows us to do), is custom-formatting on specific fields.

codeams commented 1 year ago

I know, I know, nobody should be installing stuff GPT-4 recommends without proper assessment first.

But damn, GPT and any search engine out there straight up recommending to just npm install xslx (like you would do in any reasonable, well maintained package).

After finally finding relevant docs (you really have to search for it), reading through a bunch of almost irrelevant demos, still couldn't understand why the npm package hasn't been updated in over a year.

Is it so good that it doesn't have bugs or improvements to make?

Nah, I get it now.

This was a fantastic opportunity to switch from work to my 8pm routine of dinner and watching comedy.

srl295 commented 1 year ago

@SheetJSDev

it did not make sense to continue using the public npm registry for distribution.

Hi, it's been a year since you wrote that. Please consider updating your npm entry to reflect the vulnerability status of the last posted version and to point people in the right direction? I think it would be the right thing to do for the community. Thanks!

e965 commented 1 year ago

Hey, folks! I made a little tool that allows you to continue using xlsx in your projects. More details are described here https://github.com/SheetJS/sheetjs/issues/2822#issuecomment-1668303942

I'm writing here as well, so that more people interested in solving the problem will get notified 🙂

gierschv commented 11 months ago

Maybe this package should be marked as deprecated on NPM? 🤔 That doesn't make sense to keep it available like that with an outdated and with vulnerabilities in it?

srl295 commented 11 months ago

I suggested that.

Do the responsible thing, SheetJS!

El El lun, oct. 2, 2023 a la(s) 5:44 a.m., Vincent Giersch < @.***> escribió:

Maybe this package should be marked as deprecated on NPM? 🤔 That doesn't make sense to keep it available like that with an outdated and with vulnerabilities in it?

— Reply to this email directly, view it on GitHub https://github.com/SheetJS/sheetjs/issues/2667#issuecomment-1742788412, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGQZM2FU47CELSE7LJI2UTX5KLJNANCNFSM5UNOGEVA . You are receiving this because you commented.Message ID: @.***>

esschul commented 9 months ago

Pretty please with sugar on top, please release on NPM, You'll fix millions of problems. You remember that song from Mariah Carey? "And then a hero comes along, with the strength to carry on". That will be playing in the background as you do it.

jakemitchellxyz commented 3 months ago

oof.

ryenus commented 2 weeks ago

Top 500 NPM package list, 1.26 million downloads a week, over 3000 dependent packages and not even a mention in the README regarding the fact ongoing development for this package won't exist any longer in the single largest JS library platform on the planet (after 8 years).

Is sheetjs sold or will it be?

SheetJS / sheetjs

Why the move away from npm registry? #2667