Why the move away from npm registry? #2667

I noticed from this ed18acd63d 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.

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.

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.

<img width="542" alt="npm" src="https://user-images.githubusercontent.com/6070939/165421103-c2909aa8-4e58-4452-976a-2cc4dd8e959e.png"> 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](https://github.blog/changelog/2022-04-25-git-io-deprecation/), we are reminded of the ephemerality of the Internet and the inherent risks of relying on platforms.

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).

🤔

> 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). 🤔

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.

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.

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

This is bizarre

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.

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](https://github.blog/changelog/2022-04-25-git-io-deprecation/), 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.

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?!

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?!_

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

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

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 ```

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.

[npm package xlsx](https://www.npmjs.com/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.

Hilarious.

@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.

@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.

Highly disappointing that you won't reply to any of the above comments raised by users of SheetJS or at least post a notice on the npm readme.

Means millions still install from npm with no idea, and many must be paying for the pro version without realising what has happened. As someone said above, npm will be here forever basically wheras this CDN could end at any date.

Highly disappointing that you won't reply to any of the above comments raised by users of SheetJS or at least post a notice on the npm readme. Means millions still install from npm with no idea, and many must be paying for the pro version without realising what has happened. As someone said above, npm will be here forever basically wheras this CDN could end at any date.

While I do understand that there is more going on here than meets the eye I would like to raise an additional issue that is caused by this.

In the deployment pipeline of my company, access to the open internet is not possible for security reasons. We have our own registry which is basically a mirror of npm and we have the same for other popular registries (e.g. pip or Docker). This means that our build can only depend on things that are either on npm or already inside a project's repository. Anything besides that is strictly off limits and we are unable to get around this even with a proper proxy configuration.

We are therefore unable to use the latest version in production.
Whatever your matter with npm is, you should consider whether this drastic step is actually necessary. After all, it is only to your disadvantage because people keep using your project via npm but are not using the latest versions. This will hurt the project in the long term.

If this doesn't change within the next few months I will have no choice but to replace SheetJS with something else.

While I do understand that there is more going on here than meets the eye I would like to raise an additional issue that is caused by this. In the deployment pipeline of my company, access to the open internet is not possible for security reasons. We have our own registry which is basically a mirror of npm and we have the same for other popular registries (e.g. pip or Docker). This means that our build can only depend on things that are either on npm or already inside a project's repository. Anything besides that is strictly off limits and we are unable to get around this even with a proper proxy configuration. We are therefore unable to use the latest version in production. Whatever your matter with npm is, you should consider whether this drastic step is actually necessary. After all, it is only to your disadvantage because people keep using your project via npm but are not using the latest versions. This will hurt the project in the long term. If this doesn't change within the next few months I will have no choice but to replace SheetJS with something else.

Labels Milestones

Why the move away from npm registry? #2667