Upcoming breaking changes for NPM v12(github.blog)
90 pointsby plasma2 hours ago9 comments
  • Tiberium2 hours ago
    I hope GitHub changes their vibecoded badges, what does RETIRED even signify in this context? Why does the preview have to be in ominous red?
    • mort96an hour ago
      Hahaha that's amazing, just a big red "RETIRED" badge above their blog post? What the hell
      • petetntan hour ago
        Breaking changes have had that tag for ages
        • mort9634 minutes ago
          Really? Retired? What does that even mean in this context, why not "breaking" or something else that suggests breaking change?
    • sheept28 minutes ago
      The changelog design has been like that since last year,[0] which predates today's slop design of small caps and monospace text (probably because they both are based on the same design trend). A year ago, vibe coded websites leaned more on sans serif and gradient text.

      [0]: https://github.blog/changelog/2025-05-05-improvements-to-cha...

  • efortisan hour ago
    this release fixes a vulnerability reported 10 years ago

    https://www.kb.cert.org/vuls/id/319816

  • karakanb24 minutes ago
    It is not obvious from the post but it seems like the allow list for the scripts supports whitelisting packages instead of a global setting. This should make it easier to maintain org-wise rules to allow scripts only for specific packages.

    Is there a linter that could be used for scenarios like this to prevent unsafe default on package manager config?

  • ComputerGuru21 minutes ago
    My big question as an OSS dev distributing some precompiled binaries via npm for easy installation: does allowScripts also default to disabled when directly installing a package (globally or otherwise)?
  • heldrida29 minutes ago
    > The resulting allowlist is written to package.json

    Couldn’t this effectively result in the same process we get in pre-12 defaults?

  • aniceperson2 hours ago
    didn't know npm was owned by github.. well, that explains things...
    • shagiean hour ago
      NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (March 16, 2020; 571 comments; 1829 points) - https://github.blog/news-insights/company-news/npm-is-joinin...

      Some of it aged... interesting.

      Top comment:

      > Microsoft doesn’t do everything right but the GitHub acquisition has honestly gone better than I ever expected. Rather than forcing GitHub to adopt Microsoft centric policies, Microsoft has adopted more GitHub stuff, especially from a product POV. GitHub still runs as a separate company (different logins and health care and hiring systems) with its own policies and point of view.

      > ...

      • w29UiIm2Xz27 minutes ago
        To be fair, the vibes (at the time) were that Microsoft has changed. Probably, in some way, a zero-interest rate phenomena.
    • joeyhage2 hours ago
      Most people know this but the _real_ reason it explains things is that GitHub is owned by Microsoft. Oh, and Microsoft moved GitHub to Azure
    • BowBunan hour ago
      yes, since 2020
  • Zopieux34 minutes ago
    Eh, that only took a few dozen actively exploited supply-chain vulns in the span of two years!
    • dawnerd13 minutes ago
      Only took Microsoft themselves getting hit with it for things to change.
  • cute_boian hour ago
    They should have added a 1-day age limit by default, so security scanners have some time.
    • KolmogorovCompan hour ago
      I don't think it'd necessarily be a good decision, sometimes CVE are actively exploited and need quick patching.

      A better safety net would be to require active 2FA proof for every package update.

      • jnwatsonan hour ago
        If you need a quick patch, you pass another parameter to turn off the 1 day. 1 day delay will prevent more problems than it makes.
  • TZubirian hour ago
    Looks good? But doesn't this just change the compromise window from first installation to first run?
    • semiquaveran hour ago
      Ok? Not sure what a package manager can do about the fact that eventually you want to run the things you install.
    • grassfedgeekan hour ago
      "First run" doesn't exist for JavaScript libs used only in web apps. So for that entire class of packages this change makes them safe.
    • insanitybitan hour ago
      Yes, but that's actually a huge win. I can't know what a package needs to do at install time - the dev knows that. But I know what my tests and program need to do at runtime because it's my job to understand those things.

      The dev has to be responsible for ensuring that their build scripts are safe, I need to be responsible for ensuring that my runtime is safe.

      It'd be great to have more tools for untrusting libraries (iframes are awesome for this on the frontend) but this is still a massive win.

    • christophilusan hour ago
      Better than nothing. That’s the same problem every package manager has.
    • Someone1234an hour ago
      I’m sure we’d all welcome your alternative and or superior proposals.

      Without that, this just comes across like unconstructive commentary.

      This moves the needle a little your proposals or the lack thereof don’t move it at all. So I’ll take this over nothing.

      • mschuster91an hour ago
        An idea might be to not just pin "package xyz allowed", but "package xyz postinstall allowed with hash <1234>".