Comments (8)
deciding between the two is really just bikeshedding.
enough said, I say lets leave this until it pops up again.
from nes.css.
@jjspace we have not faced this yet, but it might happen later. so preventing it from now using yarn should be a good idea.
from nes.css.
@iam13islucky I noticed you reacted thumbs down, do you have a reason not to switch?
from nes.css.
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.
from nes.css.
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.
from nes.css.
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.
from nes.css.
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.
from nes.css.
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.
from nes.css.
Related Issues (20)
- favicon etc are SNES not NES controllers? HOT 1
- about polyfill
- Package engine "Node >= 10.0.0" causing installation problem in Node 15.4.0 HOT 4
- Simple cool improvements for the project! HOT 1
- Visual glitch in non-rounded dark dialog HOT 1
- Form component disable style HOT 1
- Custom theme HOT 1
- radio
- NES.css react component library HOT 3
- Adding Korean translation of CONTRIBUTING.md HOT 4
- `package.json`'s `engines` field having `"Node >= 10.0.0"` prevents installation with Node 16.9.1 HOT 4
- Buttons on index.html aren't clickable
- It's look like different between chrome and debug tools.What happened?
- Adding Discord Icon HOT 4
- Adding font for Arabic HOT 1
- Change icon HOT 1
- Feat: Update Twitter icon
- Buttons and containers look .. weird on Firefox and Chrome HOT 1
- I
- G
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nes.css.