Private Github Registry NPM packages published are giving undefined shasum, unable to resolve packages. [Potential Fix in comments]

[oddlyspaced]

Select Topic Area

Bug

Body

Since last night any newly published packages are returning the following undefined details when using the command npm view

@1.71.1-p2 | Proprietary | deps: none | versions: 1525

dist
.tarball: https://npm.pkg.github.com/download/@headout/pkg/1.71.1-p2/
.shasum: undefined

dist-tags:
latest: 1.71.1-p2        oncall: 1.67.0-oncall.1  release-1.13.x: 1.13.2

published just now by undefined <undefined>

Normally it is like this :

@headout/[email protected] | UNLICENSED | deps: 7 | versions: 1523
Holds all BL and react-native-web components
https://github.com/headout/pkg.git#readme

dist
.tarball: https://npm.pkg.github.com/download/@headout/pkg/1.71.1-rc-merged/XXXXXXXXXXXXXXXXXXX
.shasum: XXXXXXXXXXXXXXXXXXX
.integrity: XXXXXXXXXXXXXXXXXXX

dependencies:
@react-native-async-storage/async-storage: ^1.17.3 fuse.js: ^6.6.2
@tanstack/react-query: ^4.28.0                     jotai: ^2.8.0
axios: ^0.26.1                                     react-native-shadow-2: ^6.0.6
dayjs: ^1.11.0

dist-tags:
latest: 1.71.1-rc-merged  oncall: 1.67.0-oncall.1   release-1.13.x: 1.13.2

published 21 hours ago by username <undefined>

Locally the pack command is generating a valid tarball. We have checked multiple things locally and are able to use the compiled tarball directly, however with npm registry because of undefined shasum, the package is not downloadable and always errors out.

Edit :
Please check this for a potential fix :
#151913 (comment)

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[leny]

Exactly same issue here on our organisation.
It worked well yesterday on published packages, and publishes of today succeed to publish but can't be downloaded, as the tarball address is incorrect & the shasum is missing.

[jbrunken]

The problem started yesterday afternoon, at least for us. I was fighting with this issue for most of the afternoon yesterday.

[MichaelSchubertTNG]

We experienced similar problems, but could make our publishes work again by removing non-standard characters (in our case 👕) from our package.json (we had that in one of our scripts).
Publishing our packages with those characters was working before today.

Edit: This also applies to other files, most prominently READMEs. See findings from @bennyk8y https://github.com/orgs/community/discussions/151913#discussioncomment-12266008

[leny]

Didn't have any non-standard character in our package.json on our side.

[oddlyspaced]

Same, no nonstandard characters

[jbrunken]

Ours either...

[bennyk8y]

Also READMDE files and probably all meta files

[GabrielePapaleo]

We're experiencing the same issue since today's package release.
When running npm view, we see an incorrect tarball link, an undefined shasum, and missing integrity and dependencies.
Everything was working fine with the previous version (released yesterday).

This issue affects all our package, none of them can publish a new version correctly.

[jbrunken]

Same issue here. I changed 1 character a tried to redeploy a package that previously deployed with no issue. Running "npx pack" on the newly deployed version results in "ERR! Invalid package, must have name and version".

Glad I found this thread!

[inbuyz]

I am also experiencing the same issue, which started today, with no significant difference from the previously successfully published package.

[thinksaydo]

Same issue here as well. Yesterday running npm publish ran successfully, but failed to actually upload the zip file it seems. The result of this is that there's not license, dependencies, or description with the package in GitHub versions, as there has been with previously published packages. We've tried everything we can to resolve this on our end, but cannot find a way to publish.

[cbertozzi]

moreover, once published a "broken" package, it is impossible to get that module also from a previous (working) version. the only way to re-enable module import is to manually delete the broken version of the package

[jensyfrenzy]

We are also experiencing this issue, however, it only seems to be happening with one of our packages.

[kbruccoleri]

Experiencing the same issue over here.

[bennyk8y]

Try removing the README file. Don't ask me why, but it worked.
Edit: Remove emojis or non standard characters from README and package.json files and probably other meta files

[rod]

Worked for us too, thanks @bennyk8y ⭐

[AronsonDan]

@bennyk8y I'm glad to see that threads discussion is working 😮

[ebndev]

Hi @bennyk8y & @jensyfrenzy, thanks for taking the time to answer!

@oddlyspaced if the responses above helped, please feel encouraged to mark it as the answer. It could be helpful for other users who might experience this in the future 😄

[oddlyspaced]

@ebndev this is only a workaround though right? Do we have another proper solution for this ?

[friday]

Yeah, just make another release. They fixed this yesterday just like Jens said.

[ishubham21]

Instead of removing non-standard characters, another solution that worked for us was upgrading Yarn to version 4.6.0, which is now a major stable release.

We followed the official step-by-step migration guide provided here: Yarn Migration Guide. However, a heads-up—upgrading Yarn may not be a viable solution for everyone, as it requires updating CI configurations, package release tooling, and other dependencies in your workflow.

[friday]

It worked because GitHub fixed the issue yesterday. You placeboed yourself 😉