search

debug-js / debug

A tiny JavaScript debugging utility modelled after Node.js core's debugging technique. Works in Node.js and web browsers
MIT License
11.15k stars 939 forks source link

Please fix the spell mistake in 2.4.0 #347

Closed hefangshi closed 7 years ago

hefangshi commented 7 years ago

https://github.com/visionmedia/debug/blob/master/debug.js#L126

https://travis-ci.org/fex-team/node-ral/jobs/183832044

codeaholics commented 7 years ago

@doublesharp don't grep package.json, do npm ls debug

doublesharp commented 7 years ago

@codeaholics Sorry, I wasn't totally clear, I did that, and then I grep'd just to double check. Everything is either 2.2.0 or 2.3.3, so I'm not sure what was grabbing the latest version of debug.

npm ls debug
├─┬ bcrypt@1.0.1
│ └─┬ node-pre-gyp@0.6.30
│   └─┬ tar-pack@3.1.4
│     └── debug@2.2.0 
├─┬ body-parser@1.15.2
│ └── debug@2.2.0 
├─┬ compression@1.6.2
│ └── debug@2.2.0 
├── debug@2.3.3 
├─┬ developer-tools@0.0.9
│ ├─┬ mocha@3.2.0
│ │ └── debug@2.2.0 
│ └─┬ nodemon@1.11.0
│   └─┬ chokidar@1.6.1
│     └─┬ fsevents@1.0.15
│       └─┬ node-pre-gyp@0.6.29
│         └─┬ tar-pack@3.1.4
│           └── debug@2.2.0 
├─┬ eslint-plugin-import@2.2.0
│ └─┬ eslint-module-utils@2.0.0
│   └── debug@2.2.0 
├─┬ express@4.14.0
│ ├── debug@2.2.0 
│ ├─┬ finalhandler@0.5.0
│ │ └── debug@2.2.0 
│ └─┬ send@0.14.1
│   └── debug@2.2.0 
├─┬ morgan@1.7.0
│ └── debug@2.2.0 
└─┬ sqlite3@3.1.8
  └─┬ node-pre-gyp@0.6.31
    └─┬ tar-pack@3.3.0
      └── debug@2.2.0

What's even more confusing is that it was working just fine on my laptop (even with deleting node_modules and running npm install) but was failing on my Jenkins server.

codeaholics commented 7 years ago

Interesting. As others have pointed out, Yarn uses (perhaps directly, perhaps transitively) debug. I know you said you aren't using Yarn, but I just checked, and so does NPM - although latest (4.0.3) still only appears to bring in debug 2.2.0. It seems like there's a difference between the versions of the tools (or the NPM config?) being used between your laptop and your CI server.

Either way, I'm guessing you're all sorted now any way.

doublesharp commented 7 years ago

@codeaholics It's all working again, but definitely confusing. FWIW - the version of node and npm is the same, and the Jenkins server deletes the workspace and installs node locally for each build... I actually just reinstalled both from scratch a few days ago so I'm certain this is the case. The only difference is my laptop is a Mac and Jenkins is on CentOS7.

yamikuronue commented 7 years ago

@thebigredgeek Let me know if you want some help setting up CI. It'll save your bacon in cases like this, and I am a QA professional by day as well as my company's build engineer, so I'm willing to offer what assistance I can. The SockDrawer team really appreciates the Debug library :) I'd love to help give something back

SpainTrain commented 7 years ago

Folks who mentioned spending time tracking down a broken dependency - you should give https://greenkeeper.io/ a shot. It creates a branch to run CI for every update to every one of your first-order dependencies. Since we started using it, we have not once had to track down which dep broke our build (e.g., I came in this morning and already knew debug had broken a couple projects :smile_cat:)

/CC @chrisatomix

tj commented 7 years ago

To the entitled people: donate some money (or time), then maybe maintainers will have more time to devote to the free software that you use every day. If you think it's ridiculous to not have CI, then send a pull-request. This is why I effectively quit OSS, it's already one-sided, don't make it worse :D.

doublesharp commented 7 years ago

Contributing to the project or just being gracious won't hurt either.

On Dec 14, 2016 10:09 AM, "TJ Holowaychuk" notifications@github.com wrote:

To the entitled people: donate some money, then maybe people will have more time to devote to the free software that you use every day.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/visionmedia/debug/issues/347#issuecomment-267109014, or mute the thread https://github.com/notifications/unsubscribe-auth/AAi4ULMXu2sixyf7WtC_Npurcqz8xcOIks5rIDDfgaJpZM4LMl7l .

joshsmith commented 7 years ago

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:

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.

thebigredgeek commented 7 years ago

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

tj commented 7 years ago

That too, industry is a mess!

yamikuronue commented 7 years ago

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.

thebigredgeek commented 7 years ago

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

doublesharp commented 7 years ago

@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.

chrisatomix commented 7 years ago

@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.

thebigredgeek commented 7 years ago

Looking for more input on V3 here: https://github.com/visionmedia/debug/issues/370

doublesharp commented 7 years ago

@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 :)

codeaholics commented 7 years ago

@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!

doublesharp commented 7 years ago

@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. :/