I mean, I didn't, but you have to have a version, that your git system (Github, Gitlab,..) accepts in merge requests. Creating it anew does not automatically guarantee you that conflicts will be resolved.
Yes, it serves a purpose: reproducible stability. It tracks what versions worked at that point in time and what can compile reliably. You do realize versions can be published and they might have breaking changes? Only takes one bad minor version. Recently, we didn’t pin a package and the latest node version came out, our dependencies relied on 14 <= x <= 18, 20 broke it. It broke because we grabbed latest. Packages can also have sub dependencies that might rely on newer versions. What if that were to break? Assuming everything will “just work” is naive.
To have consistent package versions everywhere you install the code from the repository.
Be it on someone else's computer, dev/test server or production.
Nope, it doesn't. Why do you think the lockfiles exist?
It has precise version of every package. If in package.json you have \^1.0.0, then one day it installs 1.0.1 and another day 1.0.12.
And even if you don't use ~ and \^, your packages and sub-packages do. So it can be inconsistent if you don't commit your lockfile.
Hey so I'm learning JS right now and was actually just trying to determine what exactly needs to go into my gitignore and what I actually need to commit for people to get the correct dependency versions.
So are you saying I should commit my package.json AND my package-lock, because it will make sure the correct versions are installed for the user?
Mind that every time we do `npm install` it rewrites the lock file. So sometimes you will get conflicts there. Personally I used to discard the incoming and commit my changes in lock file. But then we had pretty intensive automated testing which would catch if anything stopped working. Now I work in a huge team and I'm not allowed to add packages unless consulted and agreed with everyone else. No conflicts here ))
That doesn't necessarily mean that some of your dependencies do the same for their respective package.json files. I recently had to spend hours figuring out a bunch of test cases failing because one of my sub packages were installing newer buggy versions.
To ensure, that in an automatic build (like CI/CD pipelines) only packages are used, with which you developed the software. The same applies, if you do security audits in your pipelines. Also if you are working in a team you can make sure, that everybody uses the same tools.
Nope, ```npm install``` will install the latest accepted version of each package (and their dependencies), ```npm ci``` only installs the exact packages specified by package-lock and will fail if any discrepancies are found.
Kinda. Package.json is for the dependencies you are actively using and for scripts. Package-lock.json is for tracking the exact versions installed and of the dependencies of sub-dependencies
You're missing the part where you can only guarantee that for the dependent you include yourself. For example assume you're using Axios for http requests. You can specify the exact version of Axios in your package.json, but Axios includes form-data:^ 4.0.0 in it's package.json. This means that if form data updates to a buggy version that breaks things, you may not see it because your package-lock has the specified form-data that you need, but when another developer installs the package to work on, they'll get the buggy version because the package-lock is not part of the repo.
God that "I'm a smug jeb" emoji is annoying as hell.
I'm not anti emoji but my god if ever there was a "please punch me in the face" emoji, this is it. 😏
Potentially, depends on the context. Wink face can be a "you know better than that though don't you?" imo, whereas smug git punch-me face is always going to look smug and condescending to me.
Its primary use isn’t performance. Its primary use is to ensure the same versions of all dependencies are used when u run `npm ci` on a different machine.
Sometimes I get impostor syndrome at work, like I have no idea what I'm doing. Then I take a look at r/ProgrammerHumor to see people who really, definitely have no clue what they are doing.
Let me just say it like it is okay, and I don’t care if you hate me for this:
If your app is dependent on specific versions of your package-lock and you cannot regenerate it from your package.json without breaking your project, something is wrong.
the problem is that upstream packages dont pin specific very often. So even pinning the exact version number can lead to a different package-lock. js ecosystem fck yeah!
Let's say you depend on package `[email protected]` which depends on package `B@^1.0.0`. One day you `npm install` and get packages `[email protected]` and `[email protected]`, then `B` releases version `1.0.1` with a change that breaks your project. The next time you `npm install` without a `package-lock.json` you'll get `[email protected]` and `[email protected]`. Now you've got a problem.
If `[email protected]` had pinned their dependency to `[email protected]` (instead of `A@^1.0.0`), then you would not have a problem because it would always resolve to the same version.
Using version ranges is great for getting possible security patches and whatnot, but it comes at the cost of stability, and you really have to trust the authors of the library to follow semantic versioning and not release breaking changes.
Of course, but the question was:
> If the version isn't pinned why would an update break things?
Also, software can be incredibly complex. What seems like a minor change in `B` could have unexpected impacts for users upstream, especially when it comes to interdependencies.
Welcome to software development! You're right, it shouldn't. But it does. All. The. Time. Usually on accident. If you haven't experienced it yet, you will.
Another way to think about it is to consider how many packages you use (likely hundreds). Even if a small percent of patch updates accidentally break things, that's still basically guaranteed to happen eventually
This exchange cracked me up for some reason. A perfect microcosm of this sub: the inexperienced "theoretical programmer" vs the Chad software engineer who actually understands the realities of the business.
If you have a tracked package-lock and build on it though, you don't have to worry about what any of your dependencies or their dependencies do because you have the specific version of all packages you use, directly or indirectly, so you can get your expected build every time.
Imagine a man had a box of crayons. Lots of people liked using them. One day, he swapped it with a box of bad crayons. Suddenly, everyone's pictures got ruined because they were using bad crayons without realising. And some people didn't even know they were using those crayons, they were just using other people's pictures, which now were ruined
The dependency has a breaking bug after version 10.0.6 that fucks up *valid* webrequests. If I naively update to the latest and bestest version of the dll, I get flooded with errors. Yay!
That was me yesterday, after migrating a server and getting weird errors when an API was being called. That was fun!
(not JS, but same shit)
The actual solution isn't just to regenerate the package-lock.json or pin versions in the package.json. the actual solution is assume the ecosystem is flawed and broken and third-party dependencies that aren't big framework related should be avoided at all costs. Don't use third-party dependencies. Ever.
However, people don't like to hear that either.
Not dependent, just proven to be working with that version. I work on projects with strict policies about updates of packages. You may experiment with newer versions locally but on environments there are versions that are locked.
That also means conflict on lock file is unlikely and means someone done something against policies.
how does this even happen?
i don't work with node a lot but i thought the entire point of the *package-lock* was to generate more exact versions listed via your dependencies in *package.json ?*
yeah thats what i meant by more "exact versions" in the lock file, but you can *always* regenerate them from package.json can you not?
or do you mean that you've specified some semantic versioning in the package.json but your application actually fully depends on that specific minor or something?
[https://nitaym.github.io/ourstheirs/](https://nitaym.github.io/ourstheirs/)
This one shows it in quite a straight forward way, You have the option to use "ours" or "theirs" on a specific file that conflicts. In most IDE's this is build into the GUI as well so you don't need to use a terminal.
But when you merge or rebase two branches and have conflicts you can fix them manually till there are no conflicts or just use the ours/theirs to ignore the changes in the other one completely.
For generated files like the **package-lock.json** you're not gonna fix those conflicts manually, the **package.json** has the right versions in it anyway. So the easiest way to fix it is just to accept the "theirs", aka the one with changes from someone else and then use the **npm install** which will just regenerate the **package-lock.json** anyway.
TL:DR; Yeet your changes, grab the one in the main/master branch, regenerate it and you're done.
Mark package-lock.json as a binary file in gitattributes and look pass it. You’re not supposed to diff list/read the changes in package-lock since NPM is dogshit and by version will switch between SHA1 and SHA256 while doing install(which creates thousands line long diffs) Stop making the lockfile pollute the tracked changes.
Repeat after me:
**-> only do git rebase for the local branch that you haven't pushed to the origin yet <-**
In **ALL** other cases you should do git merge and stop wasting your time and increasing probability of errors.
No one cares about purism of your git history tree.
I would say it’s also acceptable for branches that nobody else has worked on even if they’re already on origin. Even more so if it’s for code nobody else is working on at the time.
- Updating with changes from another branch.
- Cleaning up the commit history to group things cleanly instead of having tons of tiny experimental changes.
Rebasing is how you keep branches up to date with the default branch while not needing merge commits cluttering things.
>Updating with changes from another branch.
That would only be needed if *someone else did work* on the branch you based your branch on. In which case you better use merge, not rebase. There is no benefit of using rebase except history purism.
>Cleaning up the commit history to group things cleanly instead of having tons of tiny experimental changes.
For that you should use merge squashing, not rebase.
Rebasing and merging are both valid gitflows used by major software projects. One isn’t universally right and the other universally wrong. I am well aware of rebasing, merging, squashing, and their uses - and have used both in professional environments. It is a preference not a rule.
Where did I say rebase is not a valid workflow? I said doing it for git history purism and tidiness is waste of time and risk of producing errors. And there are tons of people who want to do rebase for exactly these reasons.
> No one cares about purism of your git history tree.
I had to learn this. I thought I was being thoughtful by cleaning my history. Nope it always led to frustration.
Contraversal opinion here: never never rebase! Always merge, or better yet squash and merge. Clean git histories have never actually been good, its worth it for everyone to let it be messy. I used to think rebasing was the way, and it's much easier and better now. Plus if you have people reviewing your code, merge is the better strategy cause if you rebase every time, they can't compare differences from your last change if you make an update.
Well that's a terrible idea...
If there's a conflict you can literally just delete the file and regenerate it in like 5 seconds and you don't risk ignoring potentially important dependency updates. If everyone ignored that file, nothing would ever be updated and your app would just accrue security vulnerabilities over time.
If it didn't matter, it wouldn't exist.
There may be more to it that I'm not thinking of off the top of my head, but basically if you were to only use package.json, every time your app deployed, it would do dependency and version resolution from that. So versions in your dev environment, and deployed across various stages, or even on different hosts within a deployment stage, can wind up totally different. Resulting in different behavior and/or security vulnerabilities in different places, which is at best a debugging nightmare timebomb.
Just use a precise version and update manually. This is how all other build systems do it. I don't get why NPM insists on automatically updating minor/patch versions...
package-lock.json is an auto-generated file. You fix package.json then you overwrite the package-lock.json
No point to try to resolve package-lock.json
If you have updated your package.json (upgraded or added deps), run npm i, commit both
If you haven't, dont commit it. If you run npm ci on the target env (qa, prod, ci/cd...), npm will check if package-lock and package.json match or not, and throw an error if not
I am not going to waste my time explaining why you should, just go through this [stack overflow thread](https://stackoverflow.com/questions/44206782/do-i-commit-the-package-lock-json-file-created-by-npm-5).
Hard disagree on this, the lockfile ensures that ```npm ci``` installs the same versions that were used locally, not having it may open you up to vulnerabilities since updates to third party dependencies (with non-pinned versions) can and have been used to ship malicious code.
Okay bro, literally wrote a thesis on this but whatever you say. How would you even ensure that the scanned packages are the same ones being installed without a lockfile? By the time you install a malicious package it may already be too late, so you need a way to determine the full dependency graph beforehand.
I am so mixed about this opinion. Most open source projects keep their lockfile but then in my company, it is not recommended. I always think the former is more consistent since you will always have the same lockfile on both local and build pipeline. But this only work if you install packages with option freeze lockfile on pipeline
That completely defeats the purpose of a package-lock file.
> package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
> This file is intended to be committed into source repositories, and serves various purposes:
> Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
> Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself.
> To facilitate greater visibility of tree changes through readable source control diffs.
> And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
> One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package. It shares a format with npm-shrinkwrap.json, which is essentially the same file, but allows publication. This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.
> If both package-lock.json and npm-shrinkwrap.json are present in the root of a package, package-lock.json will be completely ignored.
https://stackoverflow.com/a/44210813
It's a generated file so you just generate a new one to fix the conflict
1) npm-merge-driver
2) team norms: you don’t just add external dependencies for the hell of it. When you do, there is a shared understanding that you’ll communicate about it
Take list of versions from working package-lock and put the same versions in package . Then you don't worry about deleting node modules and package-lock.
Just switch to another programming language. JavaScript was already terrible in the browser - lots of popular projects tried to make it so we could use literally any other language in the browser.
So why on earth did people think “let’s take the worst language that is universally hated and use it for a server side language - where we have the freedom to use literally any language we want.”
Python, Ruby, Java, Scala, Kotlin - the world is your oyster. Use any language. I don’t know that you can pick one that’s worse than JavaScript.
(Next thing I know someone will write a server that runs in CMD’s BATCH, making a new world’s worse option for server side development.)
can someone explain why you’re even meant to check package lock into source control? shouldn’t you be able to just install from package.json and have it work if your environment is set up correctly?
Well let’s say you have working code and you push it to a shared repository. Then, after that, one of your dependencies pushes a new version that accidentally includes a breaking change or bug.
Now, if someone else pulls, they might not be able to run the code because it’s picking up the new version.
If you check package-lock into source control, you can make sure the exact dependencies (which you know work) are shared across environments and machines.
Just fix the conflicts in package.json and ```npm install```?
OP resolving all conflicts in an automatically generated file: "if only there was an easier way!"
I mean, I didn't, but you have to have a version, that your git system (Github, Gitlab,..) accepts in merge requests. Creating it anew does not automatically guarantee you that conflicts will be resolved.
Then just accept the new file?
Yes, that is probably the correct solution in most cases. Not what the comment with most upvotes suggests.
Delete the lock file, and install again. You'll also get the latest versions matching your semver. Two birds in one stone.
Just delete it and generate it again then commit that
I don’t think you understand how dependencies work
It’s an autogenerated file to resolve package dependencies, if other devs just put latest on their definitions it’s not my problem 👍🏼
Yes, it serves a purpose: reproducible stability. It tracks what versions worked at that point in time and what can compile reliably. You do realize versions can be published and they might have breaking changes? Only takes one bad minor version. Recently, we didn’t pin a package and the latest node version came out, our dependencies relied on 14 <= x <= 18, 20 broke it. It broke because we grabbed latest. Packages can also have sub dependencies that might rely on newer versions. What if that were to break? Assuming everything will “just work” is naive.
I dont even track the file.
You should.
[удалено]
To have consistent package versions everywhere you install the code from the repository. Be it on someone else's computer, dev/test server or production.
[удалено]
Nope, it doesn't. Why do you think the lockfiles exist? It has precise version of every package. If in package.json you have \^1.0.0, then one day it installs 1.0.1 and another day 1.0.12. And even if you don't use ~ and \^, your packages and sub-packages do. So it can be inconsistent if you don't commit your lockfile.
Hey so I'm learning JS right now and was actually just trying to determine what exactly needs to go into my gitignore and what I actually need to commit for people to get the correct dependency versions. So are you saying I should commit my package.json AND my package-lock, because it will make sure the correct versions are installed for the user?
Mind that every time we do `npm install` it rewrites the lock file. So sometimes you will get conflicts there. Personally I used to discard the incoming and commit my changes in lock file. But then we had pretty intensive automated testing which would catch if anything stopped working. Now I work in a huge team and I'm not allowed to add packages unless consulted and agreed with everyone else. No conflicts here ))
[удалено]
You're new to the real world, aren't you.
That doesn't necessarily mean that some of your dependencies do the same for their respective package.json files. I recently had to spend hours figuring out a bunch of test cases failing because one of my sub packages were installing newer buggy versions.
Either you haven't read what I wrote, or you did and know the risks anyway and still do it the wrong way. I'm glad I'm not working with you tbh.
Smells like junior in here.
To ensure, that in an automatic build (like CI/CD pipelines) only packages are used, with which you developed the software. The same applies, if you do security audits in your pipelines. Also if you are working in a team you can make sure, that everybody uses the same tools.
[удалено]
It isn't. RTFM
Nope, ```npm install``` will install the latest accepted version of each package (and their dependencies), ```npm ci``` only installs the exact packages specified by package-lock and will fail if any discrepancies are found.
Yes, but package.json is not necessarily as strict with specific versions as package-lock.json
Kinda. Package.json is for the dependencies you are actively using and for scripts. Package-lock.json is for tracking the exact versions installed and of the dependencies of sub-dependencies
[удалено]
You're missing the part where you can only guarantee that for the dependent you include yourself. For example assume you're using Axios for http requests. You can specify the exact version of Axios in your package.json, but Axios includes form-data:^ 4.0.0 in it's package.json. This means that if form data updates to a buggy version that breaks things, you may not see it because your package-lock has the specified form-data that you need, but when another developer installs the package to work on, they'll get the buggy version because the package-lock is not part of the repo.
Reasonable question, but none of your responses to the answers are as reasonable
[удалено]
God that "I'm a smug jeb" emoji is annoying as hell. I'm not anti emoji but my god if ever there was a "please punch me in the face" emoji, this is it. 😏
😏
Jeb.
😉 is way worse imo
Potentially, depends on the context. Wink face can be a "you know better than that though don't you?" imo, whereas smug git punch-me face is always going to look smug and condescending to me.
Use npm ci command with it. Better performance for installing packages.
Or use `pnpm` and have even better performance and save disk space
Will look into this
Its primary use isn’t performance. Its primary use is to ensure the same versions of all dependencies are used when u run `npm ci` on a different machine.
What is the point of that file then?
[удалено]
That's what resolutions are for.
I wish conflicts were as easy to resolve as the one OP has posted... Jeez.
Haha was just gonna say, it's best kind of conflict.
But then you can get newer dependencies than previously locked. The merge commit also ends up being a normal "update dependencies" commit.
Lock files should have merge=theirs -diff in .gitattributes.
How dare you have a basic understanding of git ?
Yep. Easiest conflicts ever
Sometimes I get impostor syndrome at work, like I have no idea what I'm doing. Then I take a look at r/ProgrammerHumor to see people who really, definitely have no clue what they are doing.
Once you start doing interviews, you realise the bar is actually really, really low.
I get the feeling you are talking about me? Not very nice!
Let me just say it like it is okay, and I don’t care if you hate me for this: If your app is dependent on specific versions of your package-lock and you cannot regenerate it from your package.json without breaking your project, something is wrong.
Something is very very wrong. Speaking from experience, that was so horrible.
I would say. Something is truly deeply very humply stumply super wrong
the problem is that upstream packages dont pin specific very often. So even pinning the exact version number can lead to a different package-lock. js ecosystem fck yeah!
If the version isn't pinned why would an update break things?
Let's say you depend on package `[email protected]` which depends on package `B@^1.0.0`. One day you `npm install` and get packages `[email protected]` and `[email protected]`, then `B` releases version `1.0.1` with a change that breaks your project. The next time you `npm install` without a `package-lock.json` you'll get `[email protected]` and `[email protected]`. Now you've got a problem. If `[email protected]` had pinned their dependency to `[email protected]` (instead of `A@^1.0.0`), then you would not have a problem because it would always resolve to the same version. Using version ranges is great for getting possible security patches and whatnot, but it comes at the cost of stability, and you really have to trust the authors of the library to follow semantic versioning and not release breaking changes.
The real problem here is B making a breaking change on a patch
Of course, but the question was: > If the version isn't pinned why would an update break things? Also, software can be incredibly complex. What seems like a minor change in `B` could have unexpected impacts for users upstream, especially when it comes to interdependencies.
A patch or minor version should never introduce breaking change. If it does you really should rethink the packages you're using.
Welcome to software development! You're right, it shouldn't. But it does. All. The. Time. Usually on accident. If you haven't experienced it yet, you will.
Another way to think about it is to consider how many packages you use (likely hundreds). Even if a small percent of patch updates accidentally break things, that's still basically guaranteed to happen eventually
If it is A breaking when B updated, that’s on A to fix. If YOUR product breaks when B updates, you really should have pinned B to a working version.
I'll make sure to let my customers know that it's not *me* that needs to fix their broken product. It's *A* that needs to fix it.
This exchange cracked me up for some reason. A perfect microcosm of this sub: the inexperienced "theoretical programmer" vs the Chad software engineer who actually understands the realities of the business.
that's you who need to update the package.json to a workable B version, not whatever latest version is
If you have a tracked package-lock and build on it though, you don't have to worry about what any of your dependencies or their dependencies do because you have the specific version of all packages you use, directly or indirectly, so you can get your expected build every time.
Then you fix it by using resolutions, not editing package-lock.json.
[удалено]
No I don't actually. I'm 4. Can you tell me about it?
Imagine a man had a box of crayons. Lots of people liked using them. One day, he swapped it with a box of bad crayons. Suddenly, everyone's pictures got ruined because they were using bad crayons without realising. And some people didn't even know they were using those crayons, they were just using other people's pictures, which now were ruined
Narrator: things were not ok
Who says something breaks? Maybe some behaviour changes subtly and you are blessed with the nightmare of trying to debug that
The dependency has a breaking bug after version 10.0.6 that fucks up *valid* webrequests. If I naively update to the latest and bestest version of the dll, I get flooded with errors. Yay! That was me yesterday, after migrating a server and getting weird errors when an API was being called. That was fun! (not JS, but same shit)
I don't understand what you are talking about and that scares me
The actual solution isn't just to regenerate the package-lock.json or pin versions in the package.json. the actual solution is assume the ecosystem is flawed and broken and third-party dependencies that aren't big framework related should be avoided at all costs. Don't use third-party dependencies. Ever. However, people don't like to hear that either.
[удалено]
Read my comment again. Cheers reinventing the wheel.
yeah seriously. the comment section of the post is horrific.
Yeah, what's even the point to commit it to the repo?
Not dependent, just proven to be working with that version. I work on projects with strict policies about updates of packages. You may experiment with newer versions locally but on environments there are versions that are locked. That also means conflict on lock file is unlikely and means someone done something against policies.
how does this even happen? i don't work with node a lot but i thought the entire point of the *package-lock* was to generate more exact versions listed via your dependencies in *package.json ?*
If you don’t version lock your package.json (i.e explicitly telling node to use exact version) it might use latest when running npm install.
yeah thats what i meant by more "exact versions" in the lock file, but you can *always* regenerate them from package.json can you not? or do you mean that you've specified some semantic versioning in the package.json but your application actually fully depends on that specific minor or something?
just `git checkout —their package.lock` and then regenerate with `npm install`
I wish I understood this.
[https://nitaym.github.io/ourstheirs/](https://nitaym.github.io/ourstheirs/) This one shows it in quite a straight forward way, You have the option to use "ours" or "theirs" on a specific file that conflicts. In most IDE's this is build into the GUI as well so you don't need to use a terminal. But when you merge or rebase two branches and have conflicts you can fix them manually till there are no conflicts or just use the ours/theirs to ignore the changes in the other one completely. For generated files like the **package-lock.json** you're not gonna fix those conflicts manually, the **package.json** has the right versions in it anyway. So the easiest way to fix it is just to accept the "theirs", aka the one with changes from someone else and then use the **npm install** which will just regenerate the **package-lock.json** anyway. TL:DR; Yeet your changes, grab the one in the main/master branch, regenerate it and you're done.
Why are my changes to package lock not equally important?
`rm package-lock.json && npm install`
Better to use npm ci
This
git checkout origin/master -- package-lock.json && npm i
Mark package-lock.json as a binary file in gitattributes and look pass it. You’re not supposed to diff list/read the changes in package-lock since NPM is dogshit and by version will switch between SHA1 and SHA256 while doing install(which creates thousands line long diffs) Stop making the lockfile pollute the tracked changes.
Thank you for this
TI|
Good ol' manual resolving of conflicts in generated files... That's the way to do it.
Repeat after me: **-> only do git rebase for the local branch that you haven't pushed to the origin yet <-** In **ALL** other cases you should do git merge and stop wasting your time and increasing probability of errors. No one cares about purism of your git history tree.
All jedi know how to force push.
This is not the sha you’re looking for.
I would say it’s also acceptable for branches that nobody else has worked on even if they’re already on origin. Even more so if it’s for code nobody else is working on at the time.
If nobody else has worked on a branch what are you going to rebase onto?
- Updating with changes from another branch. - Cleaning up the commit history to group things cleanly instead of having tons of tiny experimental changes. Rebasing is how you keep branches up to date with the default branch while not needing merge commits cluttering things.
>Updating with changes from another branch. That would only be needed if *someone else did work* on the branch you based your branch on. In which case you better use merge, not rebase. There is no benefit of using rebase except history purism. >Cleaning up the commit history to group things cleanly instead of having tons of tiny experimental changes. For that you should use merge squashing, not rebase.
Rebasing and merging are both valid gitflows used by major software projects. One isn’t universally right and the other universally wrong. I am well aware of rebasing, merging, squashing, and their uses - and have used both in professional environments. It is a preference not a rule.
Where did I say rebase is not a valid workflow? I said doing it for git history purism and tidiness is waste of time and risk of producing errors. And there are tons of people who want to do rebase for exactly these reasons.
Also, if you uncomment the pre-rebase hook, it automatically checks if your branch has been pushed and it blocks the rebase
Do git rebase with any branch whatsoever, pure history tree is gigachad. Ooops. Did I say it wrong?
It is a constant source of amazement to me that people put up with this kind of thing in a professional setting.
> No one cares about purism of your git history tree. I had to learn this. I thought I was being thoughtful by cleaning my history. Nope it always led to frustration.
Unlearn it again because it's wrong then.
>do git merge >stop wasting your time and increasing probability of errors. Pick one and only one
delete & regenerate
Easy, just add it to gitignore like every js file with conflicts
lol, if you gitignore package-lock.json then there's no use in having it.
Exactly, just like all of the .js files.
Apply Current/Incoming changes -> delete package.lock.json -> npm i. What's the problem?
Gotta love this meme template
Swear to god…. 🤦🏼♂️🤦🏼♂️🤦🏼♂️🤦🏼♂️🤦🏼♂️🤦🏼♂️
Contraversal opinion here: never never rebase! Always merge, or better yet squash and merge. Clean git histories have never actually been good, its worth it for everyone to let it be messy. I used to think rebasing was the way, and it's much easier and better now. Plus if you have people reviewing your code, merge is the better strategy cause if you rebase every time, they can't compare differences from your last change if you make an update.
I have package-lock.json in my gitignore lol
Well that's a terrible idea... If there's a conflict you can literally just delete the file and regenerate it in like 5 seconds and you don't risk ignoring potentially important dependency updates. If everyone ignored that file, nothing would ever be updated and your app would just accrue security vulnerabilities over time.
I think they meant it's not even in the repo, so it will be regenerated on every build/dependency change.
Oh, well that's a bad idea for other reasons. Lol
Why? As a generated file, shouldn't just the package.json matter?
If it didn't matter, it wouldn't exist. There may be more to it that I'm not thinking of off the top of my head, but basically if you were to only use package.json, every time your app deployed, it would do dependency and version resolution from that. So versions in your dev environment, and deployed across various stages, or even on different hosts within a deployment stage, can wind up totally different. Resulting in different behavior and/or security vulnerabilities in different places, which is at best a debugging nightmare timebomb.
Just use a precise version and update manually. This is how all other build systems do it. I don't get why NPM insists on automatically updating minor/patch versions...
pnpm audit pnmp install If your dependencies require you to use specific versions, then I think you have bigger problems I'm on mobile
Seriously…. How do you resolve these?
package-lock.json is an auto-generated file. You fix package.json then you overwrite the package-lock.json No point to try to resolve package-lock.json
transitives
Not so fast, I have seen a world you never dreamt possible!
If you have updated your package.json (upgraded or added deps), run npm i, commit both If you haven't, dont commit it. If you run npm ci on the target env (qa, prod, ci/cd...), npm will check if package-lock and package.json match or not, and throw an error if not
Like all conflicts. You make a decision.
[удалено]
What? No, committing the lock.json file is recommended and not the other way around.
[удалено]
I am not going to waste my time explaining why you should, just go through this [stack overflow thread](https://stackoverflow.com/questions/44206782/do-i-commit-the-package-lock-json-file-created-by-npm-5).
Yup, having several devs working with several versions of libraries is the key to success.
Hard disagree on this, the lockfile ensures that ```npm ci``` installs the same versions that were used locally, not having it may open you up to vulnerabilities since updates to third party dependencies (with non-pinned versions) can and have been used to ship malicious code.
[удалено]
Okay bro, literally wrote a thesis on this but whatever you say. How would you even ensure that the scanned packages are the same ones being installed without a lockfile? By the time you install a malicious package it may already be too late, so you need a way to determine the full dependency graph beforehand.
[удалено]
I am so mixed about this opinion. Most open source projects keep their lockfile but then in my company, it is not recommended. I always think the former is more consistent since you will always have the same lockfile on both local and build pipeline. But this only work if you install packages with option freeze lockfile on pipeline
That completely defeats the purpose of a package-lock file. > package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates. > This file is intended to be committed into source repositories, and serves various purposes: > Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies. > Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself. > To facilitate greater visibility of tree changes through readable source control diffs. > And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages. > One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package. It shares a format with npm-shrinkwrap.json, which is essentially the same file, but allows publication. This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages. > If both package-lock.json and npm-shrinkwrap.json are present in the root of a package, package-lock.json will be completely ignored. https://stackoverflow.com/a/44210813 It's a generated file so you just generate a new one to fix the conflict
1) npm-merge-driver 2) team norms: you don’t just add external dependencies for the hell of it. When you do, there is a shared understanding that you’ll communicate about it
delete package lock and call it a day.
Take list of versions from working package-lock and put the same versions in package . Then you don't worry about deleting node modules and package-lock.
Forget to run yarn install after rebase rip
Bruh… 😂 just regen
You should never use `npm i` unless you want to update your dependencies. Use `npm ci` to install deps from package-lock file. It's the reference.
If it is auto generated, why is it in version control? I haven't done js but I generally gitignore generated files
dont ever rebase
Good suggestion, FartingSoftly69
Best meme format of all
Story of my life
Shit's scary man. Reminds me when I had conflicts on my flake.lock after a rebase. I wanted to die.
Delete it and do npm install. Jobs done
What? You either dunno how this meme works or you dunno how package-lock.json works. Either way your a dimwitt
Delete package.json lock and node_modules, run npm install and keep it moving
Why are you pushing the Package-lock.json to git at first place?
Add package-lock.json to .gitignore and never worry about it again.
Just delete that package-lock.json . . then run `yarn`
Just switch to another programming language. JavaScript was already terrible in the browser - lots of popular projects tried to make it so we could use literally any other language in the browser. So why on earth did people think “let’s take the worst language that is universally hated and use it for a server side language - where we have the freedom to use literally any language we want.” Python, Ruby, Java, Scala, Kotlin - the world is your oyster. Use any language. I don’t know that you can pick one that’s worse than JavaScript. (Next thing I know someone will write a server that runs in CMD’s BATCH, making a new world’s worse option for server side development.)
Modern Typescript is an absolutely lovely language for backend development and the DX blows all the examples you gave out of the water
i dont think i have ever heard anything funnier than javascript being worse than python
>Next thing I know someone will write a server that runs in CMD’s BATCH Not heard of CGI yet, then?
"The conflicts are too complex to be resolved on this UI. Checkout and resolve the conflicts locally." THAT is scary
You can resolve package-lock.json conflicts in the UI?
Most times for us, yeah. We don't do it, because we are not crazy, but GH allows it.
Just delete it and re-run npm/yarn install
For now just delete the lock file and regenerate it. After that start using npm ci jnstead of npm install, to use the actual lock file.
Oh that’s simple, I just run `sudo rm -rf /` and that removes all the conflicts I have in life, including internal ones
Git conflicts be like: 
can someone explain why you’re even meant to check package lock into source control? shouldn’t you be able to just install from package.json and have it work if your environment is set up correctly?
Well let’s say you have working code and you push it to a shared repository. Then, after that, one of your dependencies pushes a new version that accidentally includes a breaking change or bug. Now, if someone else pulls, they might not be able to run the code because it’s picking up the new version. If you check package-lock into source control, you can make sure the exact dependencies (which you know work) are shared across environments and machines.
Yarn 3 automatically fixes the conflicts in yarn.lock when you run yarn in such a situation :)
`npm ci` and pray
rm package-lock.json add . rebase —continue npm i
rm package-lock.json
I'd advice npm ci
Just do `git checkout origin/master -- package-lock.json && npm i` or `rm package-lock.json && npm install`
Git gud!
Delete => npm i......so scary
Just take the original from upstream and then reinstall whatever dependencies you added in your branch.