jshttp
Deprecate package?
Since Node.js 0.10 and lower are essentially no longer used and Browserify largely replaced by tools such as Webpack and Vite it might be time to sunset this package. Perhaps the Express v5 release might be a good time to officially deprecate the package on NPM as well?
So far seems like the package is quite popular https://www.npmjs.com/package/methods
that being said, we might want to do an effort to release a new version with all the unpublished changes and maybe also taking the opportunity to revisit the CI and the dependencies that we use.
Indeed. I do wonder what is causing this large amount of downloads. This has to be because popular libraries depend on methods. Unfortunately, the analytics on NPM are quite poor and it is not really easy to see which dependents are causing most of the downloads.
I agree with the sentiment, but in practice deprecating it on NPM creates noise for people that can't/won't update yet and the package is still supported. That said, I'm strongly in favor of linking and redirecting people to the native node.js method and making a bold notice in the README about it.
I think I'd like to take a look at the other issues, e.g. https://github.com/jshttp/methods/issues/15, and maybe release a version that isn't trying to use node at all. Since there's a lot of dependents it's possible it's been used in non-node environments.
I do wonder what is causing this large amount of downloads.
It'd mostly be express@4. I'll make an issue on the Express 5 line to remove methods from usage, unless you want to? It's used here for express 5.
Sorry, I just saw https://github.com/pillarjs/router/pull/127, thanks! I'm working through my email in reverse chronological order 😄
Perhaps a notice will suffice for now then. Would you like me to create a PR for it?
Yeah I agree that we should not deprecate until 4 is well into EOL, and that we should remove in v5. I am on the fence on the notice unless we make it clear this is not a bad thing that it is used in express@4 because just like deprecating it causes churn which is unnecessary. That said, once v4 is nearing EOL I would be in favor of a message and then we can deprecate later.
Can we close this or is there more to discuss?
Can we close this or is there more to discuss?
I want to create a small adr to cover this case and in general the approach to "deprecate" packages.
So.. I will move this issue to the discussion repo :)
nevermind.. we can close it , I can't not move the issue because is in another org.