Learn More
Resend Email
39
codebytes
3y

Be me, new dev on a team. Taking a look through source code to get up to speed.

Dev: **thinking to self** why is there no package lock.. let me bring this up to boss man

Dev: hey boss man, you’ve got no package lock, did we forget to commit it?

Manager: no I don’t like package locks.

Dev: ...why?

Manager: they fuck up computer. The project never ran with a package lock.

Dev: ..how will you make sure that every dev has the same packages while developing?

Manager: don’t worry, I’ve done this before, we haven’t had any issues.

**couple weeks goes by**

Dev: pushes code

Manager: hey your feature is not working on my machine

Dev: it’s working on mine, and the dev servers. Let’s take a look and see

**finds out he deletes his package lock every time he does npm install, so therefore he literally has the latest of like a 50 packages with no testing**

Dev: well you see you have some packages here that updates, and have broken some of the features.

Manager: >=|, fix it.

Dev: commit a working package lock so we’re all on the same.

Manager: just set the package version to whatever works.

Dev: okay

**more weeks go by**

Manager: why are we having so many issues between devs, why are things working on some computers and not others??? We can’t be having this it’s wasting time.

Dev: **takes a look at everyone’s packages** we all have different packages.

Manager: that’s it, no one can use Mac computers. You must use these windows computers, and you must install npm v6.0 and node v15.11. Everyone must have the same system and software install to guarantee we’re all on the same page

Dev: so can we also commit package lock so we’re all having the same packages as well?

Manager: No, package locks don’t work.

**few days go by**

Manager: GUYS WHY IS THE CODE DEPLOYING TO PRODUCTION NOT WORKING. IT WAS WORKING IN DEV

DEV: **looks at packages**, when the project was built on dev on 9/1 package x was on version 1.1, when it was approved and moved to prod on 9/3 package x was now on version 1.2 which was a change that broke our code.

Manager: CHANGE THE DEPLOYMENT SCRIPTS THEN. MAKE PROD RSYNC NODE_MODULES WITH DEV

Dev: okay

Manager: just trust me, I’ve been doing this for years

Who the fuck put this man in charge.

rant

packages

fuck this shit

wtf

npm
Favorite
Ranter
Comments
  • 3
    3y
    Pardon my ignorance, but since package.json already contains the versions of the packages used, why we need package-lock?
  • 3
    3y
    So I guess he also doesn't use "npm ci" on the pipeline builds 🙄
  • 4
    3y
    @xoka my understanding is that it basically is needed because developers of packages that might be in your dependency tree don't bother following semvar rules, so introduce breaking changes.

    If you don't commit the package-lock.json and use "npm ci" different developers will end up with different Dependency package versions, causing all sorts of ball-aches
  • 4
    3y
    @nibor if you put absolute versions in package.json, that should also resolve it.

    Package lock seems better though.
  • 6
    3y
    @crost I think the problem is when you have several levels of nested dependencies, ie that package you added has a million dependencies on other packages, and it doesn't specify exact versions in its own package.json
  • 1
    3y
    @nibor good point. In theory though won't they stay the same of you're downloading the same artifact? Won't they have to replace their versioned package with a replacement build with the same version?
  • 1
    3y
    @crost I don't think the dependencies get packaged up in the artifacts, so when you install a package foo, that has a dependency on bar ^1.2.3, npm will download whatever the latest version of bar that satisfies the ^1.2.3 semver currently is.

    Hence the package-lock has details on the absolute versions of every installed dependency, so you know each dev install will be the same. However, if you use npm install, it will overwrite the package-lock, that's why you should use npm ci.

    It's a while since I really dug into npm, so I might be totally wrong though!
  • 1
    3y
    @nibor sounds legit to me. Thanks.
  • 6
    3y
    @Xoka it’s actually a common question! A package.json contains a list of dependency you need for a project.

    Let’s take bootstrap for example. If I start the project today and the latest version is 4.4.5, today I will install 4.4.5 but you’ll notice in your package.json that it says “bootstrap”: “^4.4.5” which means you’re allowed to install any version of bootstrap 4.X.X.

    You’re also allowed to specify an absolute, such as “bootstrap”:”4.4.5” and you will only be allowed to have 4.4.5 when any developer runs “npm install”

    The problem is that these days many dependencies have sub dependencies. For example bootstrap might have a sub dependencies of jQuery. Even if you absolute value bootstrap, you’re still at the mercy of jQuery releasing versions that work with your app.

    This is where the package lock comes into play. Imagine the lock file is a record of every dependency and sub dependency version that works with your app.
  • 2
    3y
    @codebytes awesome explanation! I have always been gitignored the package-lock file ( & since I am the only one uses Yarn instead of npm ), but thanks so much for enlightening me/us.
  • 0
    3y
    What @nibor said. You can have static versions in your package.json and micromanage your direct dependencies in any way, but without a package lock you have zero control of the packages that are dependencies of your dependencies.
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment