Closed hefangshi closed 7 years ago
see my pull request ;-) https://github.com/visionmedia/debug/pull/349
this is really a problem right now
126: debug.color = selectColor(namespae); should be namespace
Yes, this is breaking many apps.
How can this be released! This should have been caught by a very simple static analysis!
please use eslint before deploy)
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 :)
Geez, the timing!!! Same issue.
@JustFly1984 maybe you could put together a PR that adds it as a pre-commit hook
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.
I've just google ERROR in namespae..... how could this be released...
@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?
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
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.
It astonishes me that a library downloaded ~7 million times per ~month~ week has no test spec or even static analysis commit hook.
@glebec send a PR - this wasn't malicious, but it sucks. Imagine, though, if people only talked to you about your project when it broke their build. yarn.lock would fix it, or pinning a version. Have some empathy for the maintainers.
For everyone that ends up here, pasting this from the fine folks at ember-cli on their issue tracking this:
npm install --save-dev -E debug@2.3.3 && rm -rf node_modules && npm install
will force usage of a known working version in your app@knewter agreed on all counts — I'm not angry, just amazed.
@glebec I just feel bad for him. I was suggesting that you direct the amazed energy at a quick PR to help avoid the problems in the future too :)
I created a module that leverages other modules to help maintain a good development environment, including automatically running npm scripts from git hooks (using git-validate). It will create these under ./git/hooks/pre-commit as well as place .eslint
in the root and test directories. A script using the depcheck
module leverages a .depcheckrc
file for confirmation to make sure the dependencies in package.json line up to your project.
npm i -D developer-tools
npm run depcheck
npm run validate
npm run lint
This is ridiculous! Don't you have 100% coverage for such a widely used npm module???
Please tone it down, everybody. Mistakes happen. It's been about 30-40 minutes, and it's being worked on right now.
Hey guys. Apologies for the busted release. We currently don't have static analysis or tests set up. I've released 2.4.1 with a hotfix. I agree it is ridiculous. Currently adding test coverage and static analysis via eslint myself to make sure future releases don't shit the bed :)
I wasn't at all serious about the invoice, but we do currently have two developers assigned to investigate this internally.
Our yarn.lock
file was supposed to install 2.3.3
during our CI/CD process, but for some reason it jumped to the broken 2.4.0
version. This highlights an issue with our build/deploy process rather than this package itself, broken releases are always a possibility but it shouldn't be possible to install a different version to Production than on a local Development environment.
I'm starting to wonder if it's a bug in Yarn itself. It's the end of the day here for us, and luckily none of our deploys were mission-critical (again, I was joking about the invoice). Hopefully this is resolved by tomorrow, otherwise we'll use one of the above workarounds (or lock down the debug.js version in package.json
and switch back to npm install
).
Also, hopefully this means automated testing can be added to this package to prevent these issues from occurring in future. There already seems to be some great suggestions above.
Just did an npm install, and all works fine now. Shit happens, thanks for the ultrafast fix up @thebigredgeek, @diedsmiling
@chrisatomix don't worry dudes you are save 😄 you just forgot the emoticon
Aha. Just facing the issue and it is already fixed :). Good job guys!
now ok
@thebigredgeek
@2.4.1 Released :tada:
@chrisatomix It's not a problem with yarn
nor your own CI/CD process. It's a general problem with the npm
ecosystem because most dependencies of projects are dynamic.
In my case, it's not a direct dependency of my project. But it's a dependency of a dependency where we don't have control anymore.
@chrisatomix it broke my build too, but I really can't figure out how - as far as I can tell everything (including dependencies) is locked to 2.3.3.
@thebigredgeek Thank you very much for the quick response and the fix.
@thebigredgeek thanks for the quick fix, and thank You and @TooTallNate for Your hard work. This kind of little mistakes make us better, so don't worry too much about it. Please keep up the great work, we really appreciate it. :)
That's an awesome thread people :) Thanks @thebigredgeek for your hard work!
Merry Xmas :)
🎉 Huge thanks to everyone who jumped on this so quickly. Your efforts are much appreciated.
@chrisatomix @doublesharp are you installing yarn using npm? yarn itself depends on debug
so if you aren't using the pre-packaged builds then that's probably your issue: https://github.com/yarnpkg/yarn/blob/master/package.json#L15
@koresar not me. Thanks to everyone who put in PRs. All I had to do was hit the merge button, run a sanity check, and publish haha.
With regards to yarn, I highly recommend installing via yum/homebrew/apt-get. You'll have a better experience
@chancancode I think you've nailed it, we assumed it was because of a browsersync dependency. Didn't realise this package was also used by Yarn itself! Definitely need to switch to pre-packaged builds.
@thebigredgeek Great advice :+1: This typo might turn out to be a blessing in disguise if it makes our builds more robust :)
害苦我了
This is a good wake up call to start using npm shrinkwrap or yarn
Glad this shit show can be a learning lesson for some of us haha
@chancancode I'm not using yarn
, this is an express
app. All is well again now that 2.4.1 has been pushed, but I can't tell what dependency is even grabbing the latest version, grepping all the package.json files shows 2.3.3.
@chrisatomix Are you using yarn in production ?
#761 is still open, which doesn't install correct dependencies on using --production
flag.
So does your production build include dev dependencies ?
cc: @thebigredgeek @awestroke
https://github.com/visionmedia/debug/commit/f77ca5d56c06a98cd81ade020a2ffbf2c73940a6 < in case anyone is interested, boilerplate for tests, linting, and v3 roadmap (ES2015 + full test coverage) has been added. Waiting on admin access to integrate with circle ci :)
@KunalKapadia Using it on our CI/CD server to compile CSS/JS files, if the build is successful then it deploys to Production. We don't actually use Yarn on our Production servers themselves. Also, all our dependencies are specified as dev dependencies, so I don't think that open issue would affect us anyway.
@thebigredgeek I just sent a PR that duplicates some of what you did and includes a few other things that might be useful, feel free to use as you please. Thanks!
@doublesharp thanks will look into it when I get some free time. Currently sick, so deploying tonight probably wasn't a great choice on my part
@halt-hammerzeit lol
thank you for the quick fix ❤️
https://github.com/visionmedia/debug/blob/master/debug.js#L126
https://travis-ci.org/fex-team/node-ral/jobs/183832044