jshttp
Release: 1.0.1
Plan to release it on Nov 06
What's included in the HISTORY.md
- Updated
enginesfield to Node@18 or higher - Remove dependency
safe-buffer
What's Changed
- Remove dependency
safe-bufferby @Phillip9587 in https://github.com/jshttp/content-disposition/pull/53 - fix: update package.json engines field to reflect minimum supported node version by @Phillip9587 in https://github.com/jshttp/content-disposition/pull/56
New Contributors
- @Phillip9587 made their first contribution in https://github.com/jshttp/content-disposition/pull/53
Full Changelog: https://github.com/jshttp/content-disposition/compare/v1.0.0...master
Hey @UlisesGascon , please consider adding #56 to the release. The commit removing the safe-buffer package is based on the assumption that only node versions v18 and newer are supported.
This should technically be a major. But, because it is our states support policy that engines should have been 18 on 1.0.0 release, I am willing to bend as long as we make this a minor (not patch like it is now).
Hey @UlisesGascon, Just wanted to kindly check if there’s an ETA for when this release might go out? Looking forward to it!
Hey @UlisesGascon, just wanted to check in on the status of this release. This is the last of Express's direct dependencies that uses the safe-buffer package. I'm looking forward to removing it from our dependency tree :-)
I will be assembling a list of releases we need to do next week. If @UlisesGascon doesn't time before then I can take this on. I will be doing two passes to make sure we release all the pending things for express first, then update them and release in express.
There are two PRs we could land before we push this:
https://github.com/jshttp/content-disposition/pull/55 https://github.com/jshttp/content-disposition/pull/54
Neither required, just wanted to call them out.
Hey @wesleytodd, @UlisesGascon, @bjohansebas, I created PR #68 that refactors the code to remove the dependency on node:path, which enhances compatibility with non-Node.js environments. Given this improvement, do you think it would be appropriate to include this change in this release and version it as v2? This would allow us to update the engines field accordingly and clearly communicate our support for a broader range of environments.
@wesleytodd @UlisesGascon Would it be possible to release v1.0.1 without the engines field change, solely to remove safe-buffer from Express' dependency tree? According to HISTORY.md, support for Node <18 has already been dropped in the v1.0.0 release, so removing safe-buffer should be safe to include in a patch release - assuming we leave the engines field unchanged.
Notably, content-disposition is the last direct dependency of express still requiring safe-buffer. Here's the full dependency graph: https://npmgraph.js.org/?q=express
@wesleytodd @UlisesGascon Would it be possible to release v1.0.1 without the engines field change, solely to remove
safe-bufferfrom Express' dependency tree? According toHISTORY.md, support for Node <18 has already been dropped in the v1.0.0 release, so removingsafe-buffershould be safe to include in a patch release - assuming we leave the engines field unchanged.Notably,
content-dispositionis the last direct dependency ofexpressstill requiringsafe-buffer. Here's the full dependency graph: https://npmgraph.js.org/?q=express
Hey @UlisesGascon @wesleytodd, what do you think?
We can revert that easily with https://github.com/jshttp/content-disposition/pull/77 and just make this release semver compatible :+1:
@UlisesGascon Just a reminder - we also need to publish this release to the latest tag on npm. Currently v0.5.4 is still marked as the latest release on npm.
Hey @UlisesGascon, I opened #79 to remove the invalid engines field. Could we move forward with releasing v1.0.1? Thanks!
Hey @UlisesGascon @wesleytodd. Just wanted to check in on the status of this release. Has there been a decision?
@wesleytodd Thanks for the approval. @UlisesGascon Can we publish this release?
Just to bring this up again: https://github.com/jshttp/content-disposition/pull/68
I will release this tomorrow unless we consider #68 a blocker... @Phillip9587 what do you recommend?
@UlisesGascon I don’t want to delay this release any further. I think we should ship it as it is and then plan a follow-up release that includes #68 and #70.