Would you want all packages you're responsible for being taken over by whomever happens to be NPM's preferred forker in the event of your getting into legal troubles? I'd be strongly against that.

This should be handled the way any other fork happens: people create forks, other people audit them for stability and choose which to update their dependencies to. This isn't up to NPM to decide.

Now Microsoft's preferred forker. Yikes!

I'd rather hear Microsoft's suggestions on libraries to use than some random Joe Developer. They have/had unethical business practices, but their tech is really good and they have very smart people working for them.

A lot of people are making fun of Microsoft but most of them don't know or appreciate that you can run software compiled in the 90s on the most recent Windows 10 1909 without problems. Microsoft's backwards compatibility is off the charts.

Try that with macOS.

Well... Windows 10 have the record of the being the only windows that breaks backwards compatibility sometimes. I saw Visual Basic 5/6 applications stooping to work because Microsoft break something on a update.

Also, good luck trying to run any Windows 16 bit application on a modern Windows 64 bit installation.

> Also, good luck trying to run any Windows 16 bit application on a modern Windows 64 bit installation.

The officially supported method is to have Windows 10 (32 bit) running in HyperV. There is no 16 bit support in Windows 10 64bit builds.

I can run Ubuntu now without worrying about hardware compatibility and I can play video games, all from Windows. I'm a fan.

Something like that happened with `leftpad` in 2016.

Finding a vulnerability in core-js which would highlight it in `npm audit` and then making a fork which fixes such vulnerability is much more ideomatic imho.

It's probably a better idea for individual depending projects (all 19k of them!) to evaluate their own use of this module. They may issue new versions with new dependencies, or they may not. It's not as if this code will start killing puppies just because the maintainer is unavailable.

I would imagine a better answer is for someone else in the community with familiarity on the project to create a semi-official fork.

Perhaps a less destructive change that someone with access (Github, NPM, Microsoft, etc.) could make, is to link to the new project from the readme.

Eventually when something breaks, this could be surfaced as an `npm audit` response (Core-js is no longer maintained. Switch to core-js-fork to resolve issue xyz).

You can: https://www.npmjs.com/policies/disputes

> This process is an excellent way to: Adopt an "abandoned" package

Harder is taking control of the GitHub project where the bug tracker lives and people are used to sending patches.

Not a great precedent, is rather have them forcefully depreciate the package, eventually, suggest a few alternatives in the error log, and let the user decide.