Official docs say it’s for

Packages that are only needed for local development and testing.

Umm, okay. Not 100% clear there. Some articles mention things like ESLint or Jest (k, I’m onboard there) but others mention Babel or WebPack. I get that you don’t need WebPack libraries to be loaded in the browser but how the hell do you bundle up your code without it? When you use npm ci or npm install you’ll get all dependencies but isn’t it good practice (in a CICD environment) to use --omit=dev or --only=prod?

  • dan@upvote.au
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    8 months ago

    Are you using Node.js on the backend, or are you just using JS for the frontend?

    In frontend JS, everything should be a dev dependency. At runtime, you only use the JS bundles generated by your bundler, which is a build-time process. That means you don’t actually directly use Node modules at runtime, just the bundled versions, so there should not be any non-dev dependencies.

    For backend JS, anything only used in dev (unit testing, mocking, bundlers, etc) should be a dev dependency, and stuff you need at runtime (like Express, etc) should be a regular dependency.

    • FooBarrington@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      I don’t think it’s accurate to say that for frontend, everything should be a devDependency. It’s more a matter of personal taste what goes where. I’ve had good experiences with using devDependencies for anything that doesn’t end up in the bundle, and everything else as a normal dependency. That seems more useful than having everything in one category.

      • dan@upvote.au
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        8 months ago

        Sure, that’s fine. I think I didn’t word my comment well. What I meant to say was that you only ever do dev installs for frontend apps, so there’s no difference between dev dependencies and regular dependencies. You can split things however you want.