Switch to Yarn over npm about nes.css

[abdallahalsamman]

deciding between the two is really just bikeshedding.

enough said, I say lets leave this until it pops up again.

[abdallahalsamman]

@jjspace we have not faced this yet, but it might happen later. so preventing it from now using yarn should be a good idea.

[jjspace]

@iam13islucky I noticed you reacted thumbs down, do you have a reason not to switch?

[iam13islucky]

NPM doesn't just ignore lock files, at least not in they're intended use. If you change dependencies, like adding new ones or updating, it updates the lock file. The intended use is for if you did a fresh install, you'd get the same dependencies, and it does that. If you absolutely don't want it to update no matter what, you set it in the package.json.

Additionally, it increases developer overhead and adds another (useless) step to new contributor onboarding. if they have a working node environment, they have NPM installed already, but they would need to install yarn, just to work on a CSS framework.

In the end, it's mostly bikeshedding, and I personally err on the side of simplicity and fewest moving pieces.

[jjspace]

I've tried to do more research on this today but it's hard to find anything that's super new/up to date. As stated in the issue I linked in the issue itself there was/is a time/version of npm which does not respect the package lock as you would expect. By default npm install would get the latest version of a package and then update the package lock file to match which is backwards. There is the command npm install --no-save which seems like it should not try to do any fuzzy version updating but through testing that my current team had done they found this was not the case. Instead npm installed the updated packages and just didn't write the changes to the package lock.

I think this will need some more discussion before being merged completely and I would love some more input and sources that prove how this all actually works. Some others I came across are here, here and here. It also seems like some of the problem stems from the difference in package lock file format between npm@v5 and npm@v6 so it might be good to have another discussion on which version of Node and npm we use while developing (doesn't really apply to actual usage as it's only css).

As far as this goes:

Additionally, it increases developer overhead and adds another (useless) step to new contributor onboarding

I dont really see a huge issue with that personally. I feel yarn is still popular enough that people may likely already be use it but if they aren't they already have npm as you say and it's not hard to have them run npm i -g yarn once and then use it like normal.

[iam13islucky]

From what I've read and tested, it will get the newest version and update the lock, but only if you've already installed it and are running npm install a second time. The package lock only does anything during the first install, as that's what the NPM team considered the use case. running npm install subsequent times is read as npm update, it seems, which is an odd choice, but it's the one they chose.

If you choose to go with yarn, that's fine by me, but I'm of the mind that this treats the package.json like law and the lock file as a first-time supplement, allowing us to keep having carefully managed package.json files like we did before lock files were ever added.

[jjspace]

running npm install subsequent times is read as npm update, it seems, which is an odd choice, but it's the one they chose.

This exactly. I dont think npm install should do anything but install the packages that are desired. If they're already installed it should just check to make sure everything was installed correctly. IMO it should Not do npm update that's what npm update is for. Granted if you're doing npm install package_name or using that to install a specific version I can see an argument to update the lock file in that case.

I'm of the mind that this treats the package.json like law and the lock file as a first-time supplement, allowing us to keep having carefully managed package.json files like we did before lock files were ever added

I partially disagree with this. I view the lock file as law and the ultimate deciding factor of which version of a package to install. This is somewhat a result of semver having fuzzy versioning with the use of ^ and ~ which the package.json specifies. I think it's good to keep packages carefully managed between many developers so the problem of "it works for me" doesn't occur. From my perspective the lock file allows us to still specify we want this fuzzy range for a package in the package.json but this is the defacto one we use in this version of the project and not whatever is the newest. This ensures that we actively update packages when we are ready which in turn ensures that we test that everything is still working. This last point is kinda moot because this project is just css so there's not really functionality that would change but I still think it's valid.

[trezy]

Personally, I use Yarn for most of my projects. However, if you have Yarn installed, you likely already have npm as well. I'd say that we could certainly stick with npm since it's probably more ubiquitous.

As for dealing with package versioning discrepancies, I'd say that if we start running into issues we can start being more judicious about our use of the package.json, i.e. locking packages to a specific version instead of a range.

Ultimately, switching to Yarn would be easier for me personally, but as @iam13islucky mentioned, deciding between the two is really just bikeshedding.