There are four different ways you could say you need to have ice cream:
I want ice cream (ice-cream: *)
I want chocolate ice cream (ice-cream: ^1.0.0)
I want chocolate ice cream with sprinkles (ice-cream: ~1.0.0)
I want chocolate ice cream with chocolate sprinkles (ice-cream: 1.0.0)
Regardless, when you get your ice cream, it's chocolate with chocolate sprinkles. You're now locked into that. If you want your friend to have ice cream, too, you can give him the lock so you're both enjoying the same ice cream. If it doesn't matter exactly having the same ice cream in this moment, though, you can just give him those instructions I called out above rather than also giving him the lock.
Now that your friend is getting ice cream without a lock, he might get:
Vanilla ice cream (ice-cream: *)
Chocolate ice cream with peanuts (ice-cream: ^1.0.0)
Chocolate ice cream with rainbow sprinkles (ice-cream: ~1.0.0)
Chocolate ice cream with chocolate sprinkles (ice-cream: 1.0.0)
If we're cool with him maybe working with different ice cream than you, then awesome! If not, if maybe he's a dude who is trying to figure out whether or not to invest millions into your ice cream and he got something totally different, then you should probably give him the lock file to make sure you guys are on the same page.
Say I have specified ice-cream: ^ 1.0.0 in package.json and given him the lock file. Now ice-cream 1.1.0 is available, shouldn't he be getting 1.1.0 because my package.json has ^ symbol specified?
package.json is for you as the developer package-lock.json is for me (or the server) as the installer
The package.json will be considered only if the lock is missing, hence the reason why they invented the lock, because the package.json is not enough to guarantee repeatability
Keeping the ice cream metaphor because I think I'm clever:
When you're starting your ice cream business, it may not actually matter what kind of ice cream. You're focused on getting marketing and a retail location and stuff like that, so strawberry ice cream wouldn't kill things right now.
But once you open your business, your customers need reliability. Now that they've seen chocolate ice cream with chocolate sprinkles on the menu, they want to keep coming back for that.
That's why there would be a difference in dev dependencies, application dependencies, but also wanting to have a specific version actually deployed every time. The app just needs ice cream, you developing might need chocolate ice cream to test consistently, but now the server should always build with chocolate ice cream with chocolate sprinkles so no quirks from peanut allergies make it into production.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are four different ways you could say you need to have ice cream:
ice-cream: *)ice-cream: ^1.0.0)ice-cream: ~1.0.0)ice-cream: 1.0.0)Regardless, when you get your ice cream, it's chocolate with chocolate sprinkles. You're now locked into that. If you want your friend to have ice cream, too, you can give him the lock so you're both enjoying the same ice cream. If it doesn't matter exactly having the same ice cream in this moment, though, you can just give him those instructions I called out above rather than also giving him the lock.
Now that your friend is getting ice cream without a lock, he might get:
ice-cream: *)ice-cream: ^1.0.0)ice-cream: ~1.0.0)ice-cream: 1.0.0)If we're cool with him maybe working with different ice cream than you, then awesome! If not, if maybe he's a dude who is trying to figure out whether or not to invest millions into your ice cream and he got something totally different, then you should probably give him the lock file to make sure you guys are on the same page.
Say I have specified ice-cream: ^ 1.0.0 in package.json and given him the lock file. Now ice-cream 1.1.0 is available, shouldn't he be getting 1.1.0 because my package.json has ^ symbol specified?
No, it reads the
package-lock.json.package.jsonis for you as the developerpackage-lock.jsonis for me (or the server) as the installerThe package.json will be considered only if the lock is missing, hence the reason why they invented the lock, because the
package.jsonis not enough to guarantee repeatabilityKeeping the ice cream metaphor because I think I'm clever:
When you're starting your ice cream business, it may not actually matter what kind of ice cream. You're focused on getting marketing and a retail location and stuff like that, so strawberry ice cream wouldn't kill things right now.
But once you open your business, your customers need reliability. Now that they've seen chocolate ice cream with chocolate sprinkles on the menu, they want to keep coming back for that.
That's why there would be a difference in dev dependencies, application dependencies, but also wanting to have a specific version actually deployed every time. The app just needs ice cream, you developing might need chocolate ice cream to test consistently, but now the server should always build with chocolate ice cream with chocolate sprinkles so no quirks from peanut allergies make it into production.