Most active commenters

    ←back to thread

    Malicious versions of Nx and some supporting plugins were published

    (github.com)
    441 points longcat | 14 comments | 27 Aug 25 01:38 UTC | HN request time: 0.473s | source | bottom
    Show context
    inbx0 ◴[27 Aug 25 14:33 UTC] No.45040282[source]▶
    Periodic reminder to disable npm install scripts.

        npm config set ignore-scripts true [--global]
    It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script.

    I know this isn't a silver bullet solution to supply chain attakcs, but, so far it has been effective against many attacks through npm.

    https://docs.npmjs.com/cli/v8/commands/npm-config

    replies(17): >>45040489 #>>45041292 #>>45041798 #>>45041820 #>>45041840 #>>45042872 #>>45043977 #>>45045311 #>>45045447 #>>45045979 #>>45046082 #>>45046981 #>>45047430 #>>45047994 #>>45049197 #>>45049793 #>>45050820 #
    1. tiagod ◴[27 Aug 25 14:48 UTC] No.45040489[source]▶
    Or use pnpm. The latest versions have all dependency lifecycle scripts ignored by default. You must whitelist each package.
    replies(3): >>45040822 #>>45041469 #>>45049075 #
    2. chrisweekly ◴[27 Aug 25 15:11 UTC] No.45040822[source]▶
    pnpm is not only more secure, it's also faster, more efficient wrt disk usage, and more deterministic by design.
    replies(1): >>45041523 #
    3. jim201 ◴[27 Aug 25 16:02 UTC] No.45041469[source]▶
    This is the way. It’s a pain to manually disable the checks, but certainly better than becoming victim to an attack like this.
    4. norskeld ◴[27 Aug 25 16:06 UTC] No.45041523[source]▶
    It also has catalogs feature for defining versions or version ranges as reusable constants that you can reference in workspace packages. It was almost the only reason (besides speed) I switched a year ago from npm and never looked back.
    replies(1): >>45043771 #
    5. mirekrusin ◴[27 Aug 25 19:13 UTC] No.45043771{3}[source]▶
    workspace protocol in monorepo is also great, we're using it a lot.
    replies(1): >>45044359 #
    6. dvfjsdhgfv ◴[27 Aug 25 19:56 UTC] No.45044359{4}[source]▶
    OK so it seems too good now, what are the downsides?
    replies(5): >>45044388 #>>45045456 #>>45046645 #>>45049226 #>>45050575 #
    7. c-hendricks ◴[27 Aug 25 19:59 UTC] No.45044388{5}[source]▶
    If you relied on hoisting of transitive dependencies, you'll now have to declare that fact in a project's .npmrc

    Small price to pay for all the advantages already listed.

    replies(1): >>45047446 #
    8. nawgz ◴[27 Aug 25 21:22 UTC] No.45045456{5}[source]▶
    ‘pnpm’ is great, swapped to it a year ago after yarn 1->4 looked like a new project every version and npm had an insane dependency resolution issue for platform specific packages

    pnpm had good docs and was easy to put in place. Recommend

    9. TheRoque ◴[27 Aug 25 23:40 UTC] No.45046645{5}[source]▶
    Personally, I didn't find a way to create one docker image for each of my project (in a pnpm monorepo) in an efficient way
    replies(1): >>45047451 #
    10. no_wizard ◴[28 Aug 25 01:53 UTC] No.45047446{6}[source]▶
    They’re moving all that to the pnpm-workspace.yaml file now
    11. no_wizard ◴[28 Aug 25 01:54 UTC] No.45047451{6}[source]▶
    That’s not really a pnpm problem on the face of it
    12. trw55 ◴[28 Aug 25 06:27 UTC] No.45049075[source]▶
    Same for bun, which I find faster than pnpm
    13. mirekrusin ◴[28 Aug 25 06:53 UTC] No.45049226{5}[source]▶
    Downside is that you have to add "p" in front, ie. instead of "npm" you have to type "pnpm". That's all that I'm aware of.
    14. Nathanba ◴[28 Aug 25 10:44 UTC] No.45050575{5}[source]▶
    A few years ago it didn't work in all cases when npm did. It made me stop using it because I didn't want to constantly check with two tools. The speed boost is nice but I don't need to npm install that often.