Rename read-pkg-up to read-package-up

[MrGadget1024]

Fixes #642
See also discussion: semantic-release/semantic-release#3352

[travi]

thanks!

[travi]

@MrGadget1024 the build failures suggest that the lockfile isnt fully up to date with the change. mind double checking that part of the update?

[MrGadget1024]

@MrGadget1024 the build failures suggest that the lockfile isnt fully up to date with the change. mind double checking that part of the update?

Let's see if that makes it happy

[gr2m]

Hmm the release failed: https://github.com/semantic-release/release-notes-generator/actions/runs/9564890549/job/26366631394 I'm confused about what's happening here, any ideas?

[MrGadget1024]

A search only finds read-pkg-up in one place:

Something is cached someplace?

[travi]

the problem here is that the release step uses the version of release-notes-generator that is a dependency of semantic-release, not the unreleased local version with this change. i'm confused why npm isnt still installing the proper dependency tree for semantic-release after this change. @MrGadget1024 to help us understand, was your lockfile modification done manually or by the npm cli?

[travi]

i think #677 will resolve the broken release process

[MrGadget1024]

was your lockfile modification done manually or by the npm cli?

Manual search and replace file edit. The package name changed..same version, the package with the new name was added but no one ever changed the pointers to that one.

[travi]

gotcha. that at least makes sense for what happened here. this is one of the cases where we needed npm's ability to have multiple versions of the same package in the same overall dependency tree.

• we needed the published version of release-notes-generator that semantic-release depended on in order to install and the local version which hadnt been published yet.
• the published version still depended on the old package that had been removed for the local version.
• semantic-release used in the release process still needed the old version.

the safest way to update a lockfile is always to let the npm cli handle the updates so that it sorts out the details like this. sometimes, npm does get a lockfile wrong or only partially updated. i know the first attempt for this PR resulted in an invalid lockfile, so i totally understand resorting to manually updating in the second attempt. my fix PR should have things resolved by updating the lockfile again with the npm cli

sorry that this made things more complex, but thanks again for the contribution!

[gr2m]

confirmed, worked this time! Good thinking @travi
https://github.com/semantic-release/release-notes-generator/actions/runs/9622722119/job/26544319060

[github-actions]

🎉 This PR is included in version 14.0.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀