51–60 of 187 posts
Earlier quoted context omitted.
npm 2.x user here. Does anybody want to share a video of the 3.x progress bar? (Easy with QuickTime or CloudApp, btw)
https://www.youtube.com/watch?v=elWIVKWhWTk
Here's a side-by-side: https://youtu.be/odoVfHHBYVM
Until recently, I had no clue iTerm was doing something weird. I just figured npm install was just ugly and incomprehensible.
Here's a side-by-side video: https://youtu.be/odoVfHHBYVM
Earlier quoted context omitted.
Could you expand on that? What causes it to be nondeterministic? I haven't had that experience but it's the second time I've read someone reference this behavior
I have a project that's shrinkwrapped. I check out a new copy of the project and run `npm install`. My co-worker does the exact same thing, his fails, yet mine successfully builds. An install of a shrink-wrapped should be deterinistic, i.e. either succeed or fail, but not both.
> The npm install command, when used exclusively to install packages from a package.json, will always produce the same tree. This is because install order from a package.json is always alphabetical. Same install order means that you will get the same tree.
> You can reliably get the same dependency tree by removing your node_modules directory and running npm install whenever you make a change to your package.json.
Maybe you're experiencing a bug, rather than some in-grained non-determinism in npm?
The funky progress bar is about the coolest thing with npm. They could let it take a minute if they wanted too and i would keep watching it with amazement.
Earlier quoted context omitted.
Not everyone is you. While I agree that flashy graphics are silly in the command line, I find color-based highlighting to be quite useful.
> Not everyone is you. Never claimed that was the case. God speed with your colors. May they bring you fame and good fortune.
Whether you claimed it is not in question. You're saying "[color in the terminal] is the work of the devil", which has a clear intent to dissuade people from coloring terminal output. Which, frankly, is insanity. Most apps do it well nowadays: --color=auto/always/never, usually defaulting to auto.
So when GP says "not everyone is you", they mean be considerate. If you want color off, you're being catered for. But don't try and push that choice on everybody who isn't you.
Earlier quoted context omitted.
Could you expand on that? What causes it to be nondeterministic? I haven't had that experience but it's the second time I've read someone reference this behavior
Here are details from the docs: https://docs.npmjs.com/how-npm-works/npm3-nondet
Earlier quoted context omitted.
> Color and terminal graphics are the work of the devil. Or you know, it's 2016, and it's npm who does it badly.
I don't even want color and terminal graphics done goodly. I code with two monochrome terminals on the screen using vim and the command line.
As an undergrad, I had a 14.4 kbps modem, and an amber WYSE terminal. With that, I was able to do contract work. It reminded me of the amber monitor I had on my Apple II ten years before. A solid phosphor CRT with no shadow mask is a fine thing.
Colors on a modern LCD are great too; give it a chance!
Earlier quoted context omitted.
Could you expand on that? What causes it to be nondeterministic? I haven't had that experience but it's the second time I've read someone reference this behavior
I have a project that's shrinkwrapped. I check out a new copy of the project and run `npm install`. My co-worker does the exact same thing, his fails, yet mine successfully builds. An install of a shrink-wrapped should be deterinistic, i.e. either succeed or fail, but not both.
Earlier quoted context omitted.
Please refrain from adding unhelpful comments to the issue.
It is tremendously unfortunate that that needs to be said at all.
I'd also like to take the time to mention that the caching system when installing / other actions is extremely inefficient (for my times I have the progress bar turned off already and this is a project with around 80 modules shared between dev / prod): https://github.com/npm/npm/issues/10890 I started on a very (I would like to emphasize very a thousand times over) basic proof-of-concept to show how much faster it co…