6 ms·

Software this popular doesn't even run a test that installs, upgrades, then uninstalls before deployment? Isn't that the most important thing the software needs

Software this popular doesn't even run a test that installs, upgrades, then uninstalls before deployment? Isn't that the most important thing the software needs to be able to do? Does NPM test anything at all before they release? Another reason to switch to yarn.

deleted 7y ago
[deleted]
floatingatoll 7y ago
All autoupdate tests will eventually fail to prevent a self-breaking autoupdate from affecting one or more users. The trick is to prepare effectively for that scenario ahead of time. For example, homebrew’s “brew doctor” command has existed for a long time, but in recent years it now comes with a litany or helpful text and other commands (including autoupdate code logic) reference it when they encounter errors.
fps_doug 7y ago
Welp, not that our product is that popular, we're selling in one country only, but there are exactly zero tests. Everything is manual. And I think this is still how the majority of projects out there do it. Not that this is great, but management, and a lot of devs don't see too much value in it, more like "nice to have if there's extra time".
- not_kurt_godel 7y ago
  That is not how the majority of professional software projects do things, and even if it were it doesn't matter because npm is not your average software project anyway. It is absolute clown status that they don't have integ tests to catch this sort of thing, and adds yet more doubt in my mind about the wisdom of using it (on top of an already considerable doubt pile).
  - aprdm 7y ago
    How do you know how majority of it isn't like this ? Having a few years of experience and having worked in 10+ companies across different industries I would be surprised if it wasn't the case.
  - emerongi 7y ago
    Pretty sure it is how the majority of software projects are doing it, but I agree that NPM is not your average software project.
  - fps_doug 7y ago
    Define "professional". If "professional" == "projects that have tests" you're probably right. ;-) Otherwise, you might've gotten lucky with your previous jobs/open source projects you contributed to. The best I've seen so far at the 4 jobs I had in my life were that some, mostly smaller, components had test suites, then others some half-arsed attempts that stopped being maintained a year or two ago, and as soon as some test stopped working because something got refactored, it was simply removed if it couldn't be fixed within a couple minutes. My previous job probably had the best test coverage, but still not integration tests. Maybe it's because people slowly become more conscious about the importance.
    - mikekchar 7y ago
      I'm still amazed that there are companies that actually test diligently (I work at one now -- I sometimes complain about our tests, but in general they are pretty darn good). Literally only 20 years ago there were a lot of places you'd be laughed out of if you suggested writing automated tests for all of your code (or even any of your code ;-) ). The first time I did TDD seriously, I thought, "I'd better hang on to this job. I'll never get another one like it". But, it seems that there are groups that are doing it, and even people who think you aren't professional unless you are doing it. It's down right amazing!
  - TeMPOraL 7y ago
    To drop another n=4 anecdote, yes, all places I worked in were more-less like that. (One reason why I dislike the terms like "professional software $something" or "industry standard" is because while they connote quality, they're defined by "as done by people who are paid to do this" and "the popular thing among people who get paid for this work", respectively. The two viewpoints - quality vs. what professionals do - are almost completely opposite in practice, given the shit show our industry is.)
- bassman9000 7y ago
  How old is the product? Have you done any decent refactoring?
de_watcher 7y ago
> Another reason to switch to yarn. Another reason to stop making dozens of different package managers. Or dozens copies of literally anything. Can you people just talk and work together? These package managers aint rocket science. Look at GNU/Linux: there are only 2 or 3 variations for everything.
- diggan 7y ago
  > Can you people just talk and work together This is a general problem in technology, not just about package managers > Look at GNU/Linux: there is only 2 or 3 variations for everything. Not true, there is probably hundreds of versions of everything (probably not bad in itself) but 2-3 popular ones that you know about. The reason why we keep seeing new package managers is because people think they can do it better than the existing stuff. And I think it's a necessary step to improvement, but some of the suggested solutions will be crap. But then sometimes something really good comes along and the ecosystem self-corrects.
- sime2009 7y ago
  > Look at GNU/Linux: there are only 2 or 3 variations for everything. Mostly false. For package management on Linux I can think of 4 just off the top of my head: * apt * rpm * apk * pacman There are bound to be more and this is not counting other approaches like AppImage and Snap.
  - benbristow 7y ago
    Don't forget portage for Gentoo and zypper for OpenSUSE
  - de_watcher 7y ago
    Totally different. He said "switch from npm to yarn". I can't imagine the phrase "switch from apt to rpm". The difference here is that there is the whole layer of distribution maintainers who do the actual work to ensure compatibility and quality. AppImage and Snap are different beasts emerged from the need to bundle proprietary software. There are around two of them like I've said.
eeZah7Ux 7y ago
> doesn't even run a test that installs, upgrades, then uninstalls before deployment That would be what Debian does - automatically. Not hipster enough.

deleted 7y ago

[deleted]

floatingatoll 7y ago

All autoupdate tests will eventually fail to prevent a self-breaking autoupdate from affecting one or more users. The trick is to prepare effectively for that scenario ahead of time. For example, homebrew’s “brew doctor” command has existed for a long time, but in recent years it now comes with a litany or helpful text and other commands (including autoupdate code logic) reference it when they encounter errors.

fps_doug 7y ago

Welp, not that our product is that popular, we're selling in one country only, but there are exactly zero tests. Everything is manual. And I think this is still how the majority of projects out there do it. Not that this is great, but management, and a lot of devs don't see too much value in it, more like "nice to have if there's extra time".

not_kurt_godel 7y ago
That is not how the majority of professional software projects do things, and even if it were it doesn't matter because npm is not your average software project anyway. It is absolute clown status that they don't have integ tests to catch this sort of thing, and adds yet more doubt in my mind about the wisdom of using it (on top of an already considerable doubt pile).
- aprdm 7y ago
  How do you know how majority of it isn't like this ? Having a few years of experience and having worked in 10+ companies across different industries I would be surprised if it wasn't the case.
- emerongi 7y ago
  Pretty sure it is how the majority of software projects are doing it, but I agree that NPM is not your average software project.
- fps_doug 7y ago
  Define "professional". If "professional" == "projects that have tests" you're probably right. ;-) Otherwise, you might've gotten lucky with your previous jobs/open source projects you contributed to. The best I've seen so far at the 4 jobs I had in my life were that some, mostly smaller, components had test suites, then others some half-arsed attempts that stopped being maintained a year or two ago, and as soon as some test stopped working because something got refactored, it was simply removed if it couldn't be fixed within a couple minutes. My previous job probably had the best test coverage, but still not integration tests. Maybe it's because people slowly become more conscious about the importance.
  - mikekchar 7y ago
    I'm still amazed that there are companies that actually test diligently (I work at one now -- I sometimes complain about our tests, but in general they are pretty darn good). Literally only 20 years ago there were a lot of places you'd be laughed out of if you suggested writing automated tests for all of your code (or even any of your code ;-) ). The first time I did TDD seriously, I thought, "I'd better hang on to this job. I'll never get another one like it". But, it seems that there are groups that are doing it, and even people who think you aren't professional unless you are doing it. It's down right amazing!
- TeMPOraL 7y ago
  To drop another n=4 anecdote, yes, all places I worked in were more-less like that. (One reason why I dislike the terms like "professional software $something" or "industry standard" is because while they connote quality, they're defined by "as done by people who are paid to do this" and "the popular thing among people who get paid for this work", respectively. The two viewpoints - quality vs. what professionals do - are almost completely opposite in practice, given the shit show our industry is.)
bassman9000 7y ago
How old is the product? Have you done any decent refactoring?

de_watcher 7y ago

> Another reason to switch to yarn. Another reason to stop making dozens of different package managers. Or dozens copies of literally anything. Can you people just talk and work together? These package managers aint rocket science. Look at GNU/Linux: there are only 2 or 3 variations for everything.

diggan 7y ago
> Can you people just talk and work together This is a general problem in technology, not just about package managers > Look at GNU/Linux: there is only 2 or 3 variations for everything. Not true, there is probably hundreds of versions of everything (probably not bad in itself) but 2-3 popular ones that you know about. The reason why we keep seeing new package managers is because people think they can do it better than the existing stuff. And I think it's a necessary step to improvement, but some of the suggested solutions will be crap. But then sometimes something really good comes along and the ecosystem self-corrects.
sime2009 7y ago
> Look at GNU/Linux: there are only 2 or 3 variations for everything. Mostly false. For package management on Linux I can think of 4 just off the top of my head: * apt * rpm * apk * pacman There are bound to be more and this is not counting other approaches like AppImage and Snap.
- benbristow 7y ago
  Don't forget portage for Gentoo and zypper for OpenSUSE
- de_watcher 7y ago
  Totally different. He said "switch from npm to yarn". I can't imagine the phrase "switch from apt to rpm". The difference here is that there is the whole layer of distribution maintainers who do the actual work to ensure compatibility and quality. AppImage and Snap are different beasts emerged from the need to bundle proprietary software. There are around two of them like I've said.

eeZah7Ux 7y ago

> doesn't even run a test that installs, upgrades, then uninstalls before deployment That would be what Debian does - automatically. Not hipster enough.