Please fix the spell mistake in 2.4.0

Activity

2. hereandnow commented on Dec 14, 2016

   

   see my pull request ;-) #349

   this is really a problem right now

3. JustFly1984 commented on Dec 14, 2016

   

   126: debug.color = selectColor(namespae);
   should be namespace

4. dashmug commented on Dec 14, 2016

   

   Yes, this is breaking many apps.

5. budde377 commented on Dec 14, 2016

   

   How can this be released!
   This should have been caught by a very simple static analysis!

6. JustFly1984 commented on Dec 14, 2016

   

   please use eslint before deploy)

   Reacted by dhaya6027, Wei Zhu, Bastian Behrens, Bryan Naegele, Tomasz Szuba, Justin Silver, Orvar, Ashwin Hegde, Yuri Golobokov, Sushant and 11 more

7. knewter commented on Dec 14, 2016

   

   Ha I just came here for the same reason. Was recording a dailydrip episode when suddenly my build, which worked moments prior, was failing during the recording :)

8. adamgoose commented on Dec 14, 2016

   

   Geez, the timing!!! Same issue.

9. knewter commented on Dec 14, 2016

   

   @JustFly1984 maybe you could put together a PR that adds it as a pre-commit hook

   Reacted by Aleksey Orekhovsky, Bryan Naegele, Nicholas Steicke and k3vin

10. chrisatomix commented on Dec 14, 2016

    

    Sending you a bill for $75 in lost earnings wasted troubleshooting 7 failed builds caused by this typo :P

    Edit: This was a joke. Please see my clarification below.

    Reacted by Bryan Naegele, Bastian Behrens, Gabriel Isenberg, Adam Brady, Michael K, Scott Cooper, Perry Mitchell, Sushant, Goran Udosic, Julian Descottes and 4 more

    Reacted by Wei Zhu, Hasan Setiawan, Nicholas Steicke and Krzysztof Balas

11. thkdog commented on Dec 14, 2016

    

    I've just google ERROR in namespae..... how could this be released...

    Reacted by Perry Mitchell

12. knewter commented on Dec 14, 2016

    

    @chrisatomix maybe don't be an absolute jerk to someone who gave away his labor for free. Did you pay him for the passing builds?

    Reacted by Bastian Behrens, josh O, Justin Silver, Adam Brady, Kristofor Salmin, Jack Tzu-Chieh Huang, Peter, Perry Mitchell, Sushant, Goran Udosic and 9 more

13. JustFly1984 commented on Dec 14, 2016

    

    sorry I have my own things to do, and I don't know how to do PR yet, and currently have no time to learn that, altho you can just edit the module by yourself until it will be fixed by module owner

14. dashmug commented on Dec 14, 2016

    

    This is a problem because the NodeJS ecosystem allows automatic updates depending on what projects use in their dependencies.

    It's much easier in Python since dependencies are usually frozen.

15. glebec commented on Dec 14, 2016

    

    It astonishes me that a library downloaded ~7 million times per month week has no test spec or even static analysis commit hook.

    Reacted by Wei Zhu, bruno yang, Gabriel Isenberg, Daniel Koch, Cody Chan, Chris Atomix, Marco Bettiolo, Charles Feng, mig-1, AndersWallin and 2 more

    Reacted by Linus Unnebäck

    Reacted by Gabriel Isenberg and Roman Nuritdinov

16. 50 remaining items

17. joshsmith commented on Dec 14, 2016

    

    To follow up on what @tj said, you can read about just how one-sided and broken this situation is in Nadia Eghbal's report, Roads and Bridges.

    If you want to help fix this problem, some thoughts:

    • Donate money to projects, for example the ones on Open Collective
    • Submit a pull request
      • This time of year you can use 24 Pull Requests
      • Find some issues on CodeTriage
      • Find some issues with First Timers Only
      • Every month we post a "Who needs contributors?" thread on HN
    • Ask maintainers if you can help triage issues
    • As @doublesharp said: at the minimum, just show some empathy
    • Push back against demanding or entitled people, but also help them to understand just how broken OSS is for maintainers

    And though I'm biased, keep an eye on https://github.com/code-corps, too, to find ways to help. Clearly the contributor funnel is broken. We also need to be kinder. Do what you can to help fix it.

    Reacted by Spain, Andrew E. Rhyne and Pinglei Guo

18. thebigredgeek commented on Dec 14, 2016

    

    I honestly don't hold it against anyone here who was upset by the broken release. The industry itself is way more high stress than it should be, with engineers working under constant pressure for 60+ hours a week and their jobs always threatened by unreasonable managers. So when a package like this breaks they flip out. I think it has less to do with OSS being broken for maintainers and more to do with the industry as a whole being dysfunctional and that dysfunction cascading into OSS

    Reacted by TJ, Matt Davis, Umashankar Subramanian, Bay, Jordan, Kyle Mathews and Chris Atomix

19. tj commented on Dec 14, 2016

    

    That too, industry is a mess!

    Reacted by Andrew E. Rhyne

20. yamikuronue commented on Dec 14, 2016

    

    Agreed. Lecturing people on github issues isn't any way to enact real change.

    I don't want to be lectured, but I'm waiting to hear back from the maintainers on my offer of help. Please stop, or I'll need to mute notifications and it'll be harder for them to get in touch with me.

21. thebigredgeek commented on Dec 14, 2016

    

    @yamikuronue if you wanna submit a PR to add coveralls integration and coverage reporting with our existing mocha tooling, it would be much appreciated :)

    Reacted by Bay and Chris Atomix

22. doublesharp commented on Dec 14, 2016

    

    @codeaholics @chancancode @chrisatomix

    I figured out how I was getting the latest version and @dashmug is correct that it is caused by semantic versioning/semver. Using npm ls debug shows the required versions, but when you grep the package.json file you see that many of them are included as "debug": "^2.3.3". The caret will result in it using the latest available version that is less than "3.0.0", so when "2.4.0" was released npm used it as an acceptable version.

    Using "debug": "2.3.3" would lock it to that version, but a lot of widely used modules use a caret range, like superagent, which is a dependency of supertest, which is being used to run tests on my Jenkins server. This is also how npm adds dependencies when you run things like npm i -S module as well as npm i -S module@1.0.0 will both result in "module": "^1.0.0" being added to your package.json. This also points to a potential security flaw with using semantic versioning for npm installs, which hadn't occurred to me previously.

23. chrisatomix commented on Dec 14, 2016

    

    @doublesharp In our case it was Yarn which was installing 2.4.0, due to this line:
    "debug": "^2.2.0",
    If we'd been using the precompiled version of Yarn instead of running npm install -g yarn our builds wouldn't have failed.

    The irony is that it turned out our CI provider already includes Yarn in their default image! We didn't realise they'd added it last month, so we were able to remove the install command from our build script. It shaved about 10 seconds off our average build time :)

    Like I said, this error might be a blessing in disguise. Especially now that everyone has realised how much of a critical component it is in so many other packages, the developer may get more support than he ever anticipated. It might even encourage the Facebook Yarn team to go through all their dependencies and make sure each one has automated testing in place.

24. thebigredgeek commented on Dec 14, 2016

    

    Looking for more input on V3 here: #370

25. doublesharp commented on Dec 14, 2016

    

    @chrisatomix For sure, I never knew about npm shrinkwrap to lock all the dependencies to a particular version until it occurred to me how npm install was handling the semantic versioning. To be honest I never really thought that much about how it worked previously. I'm planning to generate an npm-shrinkwrap.json and manage the versions manually for anything critical - which is good knowledge to gain from a few failed builds :)

26. codeaholics commented on Dec 15, 2016

    

    @doublesharp the doco for npm ls says:

    This command will print to stdout all the versions of packages that are installed, as well as their dependencies, in a tree-structure.

    If you're saying it just prints the required version, and not actually the installed version, then that seems pretty broken to me!

27. doublesharp commented on Dec 15, 2016

    

    @codeaholics You're right, there must be something screwy with my project. I just created a test project, installed supertest, and it correctly shows the installed version of debug and not the caret range. Not sure why it was showing the old versions for me (especially considering I deleted node_modules and rebuilt them... I've since actually upgraded debug, so I'm giving up trying to figure out what was going on. :/