Debug: 3.2.0 wrongly released as minor version

[mariodu]

remove support for node.js v4 is a breaking change, should publish with major version.

[jtyjty99999]

+1

[dead-horse]

this module is widely used in node community, it is hard to pin the version of debug in application's package.json.

replace all let in https://github.com/visionmedia/debug/commit/ba8a424d41e9dc6129e081ac3aa9715be6a45fbd with var can quickly resolve this problem, it doesn't hurts :)

[Qix-]

---

UPDATE: Everything should be back to normal. Read the post-mortem for more information.

---

Awkward.

Side effect of going so long between releases is stuff like this is missed.

Node 4 is out of LTS, and has been for a long while. It was last released in March of this year. The last non-LTS version was released in 2015. Please keep that in mind.

Here's what I'll do:

1. babel-ify the current version back to the stone ages for those on Node 4
2. release as 3.2.2 3.2.3 (https://github.com/visionmedia/debug/issues/603#issuecomment-420190718) 3.2.4 (https://github.com/visionmedia/debug/issues/603#issuecomment-420204372)
3. immediately deprecate >=3.2.0 <4 on npm
4. release 4.0.0 that will be identical to 3.2.1

Is that acceptable?

---

### UPDATE:

Everything should be back to normal. Read the post-mortem for more information.

---

tl;dr if you're seeing errors, make sure either 3.1.0 or 3.2.4 are being pulled. Package maintainers that use debug directly should try to upgrade to debug@4 if they don't need Node 4 support.

• A non-breaking version has been released as 3.2.4. Before commenting here or opening a new issue, please make sure that is in fact the version being pulled if you're seeing errors. Otherwise, npm should be recognizing the deprecation ranges and instead reverting to 3.1.0 (which is probably what you want).

• Versions debug@>=3.2.0 <4 have been deprecated. I have a support request in with npm regarding why the deprecation notice for 3.2.0 in particular isn't being shown, but it's being shown as deprecated correctly on the site.

• Downstream packages that do not choose to support Node 4 (that should be everyone seeing as how Node 4 is out of LTS) should upgrade to debug@4. You'll likely see better performance than 3.2.3 due to that range being very highly babel-ified.

• Downstream packages that must provide Node 4 support - if your ranges are set up to track minor changes, you shouldn't see any problems. Make sure that you're pinned to a range that, at the very least, stops at debug@4 (e.g. debug@<4). Starting at debug@4, Node 4 is no longer supported. We will not be distributing babel-ified versions for you - that will be up to you.

• Browser users should avoid 3.2.0 but should otherwise be unaffected (unless you require support for IE 8/9 in which case make sure you're pulling 3.2.1 or later).

• Users of debug that use require('debug/node') (which was originally a hotfix for babel-core that has since been removed) should pin to either < 3.2.0 or =3.2.4. You should also move away from using this import in lieu of just require('debug') as soon as possible because it never should have existed to begin with.

Post-mortem to come when it's determined the problems have been mitigated. I write some juicy^[1] post-mortems^[2] so stay tuned.

[Qix-]

@dead-horse That wouldn't work. There are a whole arsenal of things Node 4 doesn't support.

[dead-horse]

https://github.com/visionmedia/debug/issues/603#issuecomment-420176933 seems good. 👍

[jtyjty99999]

Complete solution 👍

[mariodu]

👍

[Qix-]

@mariodu @jtyjty99999 @dead-horse / anyone that's reading this: 3.2.2 is released.

Can one of the afflicted confirm that it fixes Node 4 for you?

[medikoo]

Other problem is that with v3.2 node.js file was removed. Such change is also a breaking and should not be published with minor.

Still I'm not sure if any modules which explicitly relied on 3.x are affected.

I was affected but only because I pointed v3 to deps which expected v2 but for which v3.1 was still safe to use (e.g. babel-core which requires debug/node)

[Qix-]

@medikoo what was node.js being used for? It wasn't referenced in any of the meta-information that I could see, hence why it was removed.

debug had auto-detection in from a long time ago. Simply requiring debug in Node environments had the same effect as requiring debug/node.

If it's absolutely necessary I can re-add and release 3.2.3 but I'd much rather not do so.

EDIT: I see now. It was one of those things that shouldn't have happened in the first place.

https://github.com/babel/babel/blob/eac4c5bc17133c2857f2c94c1a6a8643e3b547a7/.github/CHANGELOG-6to5.md#3015 - a patch to debug to fix a niche use-case that was really the problem of another module. This is why maintainers are taking firm stances against that now.

[medikoo]

@medikoo what was node.js being used for?

I'm not sure about intentions, but it was used here https://github.com/babel/babel/blob/v6.26.3/packages/babel-core/src/transformation/file/logger.js#L2

It wasn't referenced in any of the meta-information that I could see, hence why it was removed.

This module was publicly published, so removing it makes breaking change, no matter whether it was intentionally published or not

[Qix-]

This module was publicly published, so removing it makes breaking change, no matter whether it was intentionally published or not

Not necessarily - if it's not being used and it's not documented anywhere in the docs (nor does the source have any comments talking about what it's used for) then there was little chance in affecting the public API, hence no need to bump the major version.

a31178c8d842c192261b70085b9da9ec1333c6a8 was the commit that introduced it. It was a hot-fix for a completely unrelated module. There was even concern at the time (https://github.com/visionmedia/debug/commit/a31178c8d842c192261b70085b9da9ec1333c6a8#commitcomment-20264787) about how it was blatant technical debt.

This is what happens when you introduce technical debt with no action-plan as to how to pay it back in the future - _especially_ when you don't document it.

---

I'll re-introduce node.js in 3.2.3 begrudgingly for those using an outdated babel-core.

[medikoo]

I'll re-introduce node.js in 3.2.3 begrudgingly for those using an outdated babel-core

Thank you!

[Qix-]

No problem. 3.2.3 is published - @medikoo can you confirm that fixes it for you?

[medikoo]

No problem. 3.2.3 is published - @medikoo can you confirm that fixes it for you?

As I look, there's no node.js published with v3.2.3

[Qix-]

@medikoo right you are. Here we go again. 3.2.4 has it - give that a shot. Surprised npm didn't tell me "nothing changed" when publishing.

[rarkins]

@Qix- you just accidentally deprecated the entire package on npm:

[rarkins]

If you deprecate the version which is tagged as latest, then npmjs considers the entire package to be deprecated. Please publish 3.2.5 as latest without a deprecation notice OR set 4.0.0 as latest.

[Qix-]

You're being cached. You're looking at 3.2.4 which is correctly deprecated. Give it a few minutes and npm will show 4.0.0 as latest.

Not sure why npm is showing This package has been deprecated instead of This version of this package has been deprecated. All of my deprecate commands were run with very specific ranges/versions.

[rarkins]

@Qix- npmjs has tagged 3.2.4 as latest, not 4.0.0. Quickest way right now to fix this would be for you to publish a 4.0.1 so that it takes over latest again

Look at http://registry.npmjs.org/debug and https://www.npmjs.com/package/debug

[rarkins]

4.0.0 is back to being latest now, thanks

[Qix-]

@rarkins I set the dist-tag a while ago. I just set it again to be sure. Like I said, you're being cached.

FWIW, you don't need to release a new version just to get rid of a deprecation notice. You pass an empty string to npm deprecate in order to do that.

[rarkins]

@Qix- npm will make whatever is the most recent stable semver release as latest, not the "highest". Because you published 3.2.4 after 4.0.0, it took over as latest until you corrected the dist-tag manually. npm doesn't have logic that says "3.2.4 is less than 4.0.0 so I don't make it latest" - instead it will say "this is a stable semver tag, so it is the new latest".

If you were to publish a 3.2.5 in future without specifying the tag, you would see that it would take over 4.x as latest again (and hence cause chaos).

[Qix-]

@rarkins I understand that, thank you.

[rarkins]

Welcome. FYI, if you are ever publishing another 3.x in future, you can do it like this: npm publish --tag 3.x so that it doesn't take the default latest tag. In this example, 3.x is just an arbitrary tag, you could do npm publish --tag old instead, for example.

By the way, I think you probably should deprecate all versions < 4 though. Right now it shows up that 3.1.0 is a supported version while all other 3.x are deprecated. This will discourage or prevent some users from upgrading from 3.1.0 to 3.2.4, which is what I assume you want them to do. Also anyone running 3.1.0 or earlier will not receive deprecation warnings.

[Qix-]

@rarkins that's fine. Those versions work just fine on their own. It's not common to deprecate all old versions of packages - only those that are problematic. 3.1.0 was the version used for a year with minimal problems. Nobody should be developing on it anymore so the devDependencies that had vulnerabilities shouldn't be there anymore.

[rarkins]

So you prefer people to use 3.1.0 instead of 3.2.4? Because that's what's going to happen now. e.g. if you run npm i debug@3 it installs 3.1.0.

[Qix-]

Yes. I think it's pretty well-established that this release should have been 4.0.0 to begin with.

[rarkins]

OK, in that case maybe update the first dot point earlier? Because 3.2.4 won't be pulled anymore now that it's deprecated. I think the message is now "everyone stay on or roll back to 3.1.0, or upgrade to 4.x".

❯ npm outdated
Package  Current  Wanted  Latest  Location
debug      3.2.0   3.1.0   4.0.0  tmp

Thanks for your time!

[Qix-]

@rarkins Yep, updated that a few minutes ago.

[Qix-]

Hello everyone. I'm glad you're all here today.

---

Post Mortem

[email protected], a minor bump, was published after a few days short of a _year_ of dormancy. A few disparate changes that had accumulated in that time caused a number of breaking changes that should have warranted a full major bump (e.g. [email protected]).

The problem has since been resolved via a number of follow-up patch versions for those immediately affected (as well as those affected by caching) in addition to a deprecated range of releases to prevent further downloads of the faulty versions.

[email protected] has been released - perfectly balanced, as all things should be. If you're reading this and wondering which version of debug to use with a new project, this is it.

Background

debug has been, for the most part, entirely inactive for about a year now. There have been multiple calls to action for a new release (#598, #580, #537) since I became active just a few months ago.

After some lag in communications with other maintainers, it was time to release a new version. In that time, there had been 25 commits, some of which should have been released shortly thereafter but were not.

Further, the repository itself was in some dire need of cleanup in order to stay maintainable. debug boasts 23k dependents and 20mil/day downloads, but the code wasn't in a state that reflected that.

Due to this, a large part of the release attempted to finish some minute chores as well as pay back some technical debt accrued over the years - some of which caused a misunderstanding on my part leading to mis-evaluating a proper version bump and subsequently releasing a version that broke users still on Node 4 as well as some users of code that misused some of said technical debt.

Impact

Users still on Node 4 (and possibly older) were temporarily unable to install any packages from npm that depended upon debug, either directly or indirectly, unless the dependency was pinned, either to an exact version or a range that excluded minor bumps.

Users of babel-core@>=6.26.3 <=v7.0.0-alpha.1 were also temporarily affected due to an undocumented import used by the babel-core project, which was subsequently removed in [email protected].

Browser users on IE 8/9/10 were temporarily affected until 3.2.1 was published a few minutes after due to a mis-configured browser key in package.json. However, this was considered a 'normal' regression and browser users were otherwise unaffected by this incident.

All users of Node 6 and above should have been entirely unaffected by any of this, hence the limited response volume.

Further, the latest dist-tag seemed to take a few tries to stick, as 3.2.4 was released after 4.0.0, causing some confusion for some affected users for several minutes.

Contrary to certain claims above, at no time was the entire package marked as deprecated.

The incident lasted roughly 2 hours.

Cause

583 was submitted on June 22 and merged on June 23. It removed Node 4 (which is out of LTS) from the list of Node runtimes Travis tested against, meaning new pull requests and commits would not be tested against Node 4 for LTS reasons. It's still the opinion of the most active maintainers that this is the correct path moving forward as debug@4 drops support for Node 4 and earlier.

Further, the codebase was moved to the XO code style/linter as per #397. These changes took the form of an xo --fix call followed by several manual changes to appease the XO rules while keeping semantics the same. These changes included, among other things, moving away from archaic ES5/ES3 syntax and towards ES6 features (let, const, arrow functions, etc.) - much of which is not supported by Node 4.

These two changes in succession caused the build to be green upon the refactor to XO.

Upon reviewing the changelog in order to determine what kind of bump needed to occur, this situation was overlooked and thus a minor bump was chosen in error

There was no failure of infrastructure or mistakes made in the actual publishing routine - the cause was localized to human error in the version bump decision-making process.

Further, a second error occurred due to prolonged technical debt introduced in a31178c8d842c192261b70085b9da9ec1333c6a8. The file ./node.js was created as a hotfix for the external, unrelated package babel-core, which used this hotfix for two releases and was then removed. The hotfix to debug remained in the repository until this release.

The entry point was intended to be used as require('debug/node') and short-circuited the environment detection logic in src/index.js in order to directly include the Node version of debug (as opposed to the browser version). The reason isn't entirely clear, though it appears it had something to do with a bug further upstream in Browserify.

In any case, the hotfix was entirely undocumented - both in the Readme as well as lacking any inline comments explaining the need - and it wasn't present in any metadata (package.json, require() calls, etc.); and as part of the goal of the release was to clean out some of the 'cruft' of this codebase, it was removed.

This caused a temporary outage for a select few users who still depended on those versions of babel-core.

Mitigations

The mitigation plan was set forth in https://github.com/visionmedia/debug/issues/603#issuecomment-420176933 and executed successfully:

1. Several packages were released to both identify the problem as well as fix those affected by any caching mechanisms (as is commonly the case with large-scale regressions in the Node.js ecosystem). Those versions are explained below.
2. The new packages - starting with the first erroneous release and ending with (inclusive) 3.2.4 - were deprecated in order to prevent new downloads _not_ affected by caching mechanisms to properly revert to 3.1.0 - the version of debug that everyone has been using for nearly a year.
3. [email protected], a major bump, was released. It is identical to 3.2.1.
4. A deprecation notice was added to versions debug@>=3.2.0 <4 instructing any users that had upgraded their package manifests to either roll back, pin, or upgrade.

The versions that were released are as follows:

• 3.2.0 - original faulty release (deprecated)
• 3.2.1 - fixed a 'typical' regression for browser users (deprecated but changes are included in 4.0.0)
• 3.2.2 - mitigation for users of Node 4 who were seeing failed downloads by babel-ifying the source code to be IE8 compatible (as is used by the browser distribution build script) (deprecated)
• 3.2.3 - mitigation for users that required debug/node imports - faulty (missing "files" entry in package.json) (deprecated)
• 3.2.4 - fix for 3.2.3, adding ./node.js to the "files" key in package.json (deprecated)
• 4.0.0 - duplicate of 3.2.1 (_latest_, recommended version)

The problem related to ES6 and Node 4 has been entirely mitigated as Node 4 is no longer a target for new contributions.

The problem related to require('debug/node') has been partially mitigated as it was never documented/encouraged, thus not requiring us to support it, but might still be incorrectly used by certain projects. Further mitigation involves responding to users on a per-case basis with guidance on migration.

Conclusion

Only a portion of users were affected, and the incident lasted roughly 2 hours (release time -> time to first mitigation, which fixed the majority of those affected).

Could have been much worse - luckily it was caught quickly and it ended up not being incredibly serious.

Apologies to those affected. Thank you to everyone who barked at us - both for fixing this problem as well as doing a release in the first place.

Releases will come much more often now, especially with some of the features being discussed in the tracker.

All users of the debug package should be back to normal operation.

This concludes the incident.

---

If you're facing any other issues related to...

• faulty dependencies or Node 4 support: please respond to this issue.
• problems/bugs/questions related to the new debug@4 release: please open a new issue.

Thank you all for your patience and, again, my sincerest apologies.

[rarkins]

Contrary to certain claims above, at no time was the entire package marked as deprecated.

For a brief period, version 3.2.4 was tagged as latest as well as marked as deprecated, which has the flow-on effect of the npmjs backend treating the entire package as deprecated, as shown by this screenshot from the npmjs website:

When the npmjs website literally says "This package has been deprecated", then it's deprecated - regardless of intent. Of course, the deprecation message was instructive so users reading it would be fine, and your quick action to reset the latest dist-tag to 4.0.0 afterwards resolved the matter.

I have raised two feature requests for npm to try to prevent this type of problem in future, so if anyone is an npm.community participate please give these 2 your +1:

Prevent accidental backwards publishing of latest

Warn user if "npm deprecate" will result in deprecating the entire package

[Qix-]

For a brief period, version 3.2.4 was tagged as latest as well as marked as deprecated

Which I've explained is strange behavior on npm's part. Marking the "entire package" as deprecated would have marked all versions as deprecated - an incredibly destructive operation. That isn't what happened.

Anyway, upvoted both of those. Thanks for filing them @rarkins.

[wraithgar]

Is browser (or at least browserify) support being dropped, since 3.1.0 is the last version that works with browserify?

[TooTallNate]

Browser support is not being dropped. Please open an issue for any errors
that you are seeing.

On Tue, Sep 11, 2018 at 10:10 AM, Gar [e-mail] wrote:

Is browser (or at least browserify) support being dropped, since 3.1.0 is
the last version that works with browserify?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/visionmedia/debug/issues/603#issuecomment-420348718,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEWWKR-wJdMiJd2Tp2-D5ApTjPTcz28ks5uZ-6DgaJpZM4WivWZ
.

[ThomasGHenry]

Still broken after clearing the cache and rebuilding. I don't import debug directly. Is the intention for me to fiddle with the debug version in dependencies that I know nothing about? If this were resolved, what worked 16 hours ago, should work again now, no?

Here's how I nuked the world:
watchman watch-del-all && rm -fr $TMPDIR/react-* $TMPDIR/metro* $TMPDIR/haste-* node_modules/ package-lock.json ios/build yarn.lock && cd android && gradlew clean ; cd ..; npm cache clean --force && npm install && react-native start --reset-cache

Version/deps:

$ node --version; npm --version; react-native --version; npm ls debug
v8.11.4
5.6.0
react-native-cli: 2.0.1
react-native: 0.42.3
[email protected] /Users/thomasghenry/code/rn_apps/feathers_client/ptm_feathers
├─┬ @feathersjs/[email protected]
│ ├─┬ @feathersjs/[email protected]
│ │ └── [email protected]  deduped
│ └── [email protected] 
├─┬ @feathersjs/[email protected]
│ └── [email protected]  deduped
├─┬ @feathersjs/[email protected]
│ ├─┬ @feathersjs/[email protected]
│ │ └── [email protected]  deduped
│ ├── [email protected]  deduped
│ └─┬ [email protected]
│   ├── [email protected] 
│   ├─┬ [email protected]
│   │ └── [email protected] 
│   ├─┬ [email protected]
│   │ ├── [email protected]  deduped
│   │ └─┬ [email protected]
│   │   └── [email protected] 
│   └─┬ [email protected]
│     └── [email protected] 
├─┬ [email protected]
│ └─┬ [email protected]
│   └── [email protected] 
├─┬ [email protected]
│ └─┬ [email protected]
│   └─┬ [email protected]
│     └─┬ [email protected]
│       └── [email protected]  deduped
├─┬ [email protected]
│ └─┬ [email protected]
│   ├─┬ [email protected]
│   │ ├── [email protected] 
│   │ ├─┬ [email protected]
│   │ │ └── [email protected] 
│   │ └─┬ [email protected]
│   │   └── [email protected] 
│   └─┬ [email protected]
│     └── [email protected] 
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └── [email protected] 
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
│ │ │ └── [email protected] 
│ │ ├─┬ [email protected]
│ │ │ └── [email protected] 
│ │ ├─┬ [email protected]
│ │ │ └── [email protected] 
│ │ ├── [email protected] 
│ │ ├─┬ [email protected]
│ │ │ └── [email protected] 
│ │ ├─┬ [email protected]
│ │ │ └── [email protected] 
│ │ ├─┬ [email protected]
│ │ │ └── [email protected] 
│ │ ├─┬ [email protected]
│ │ │ └── [email protected] 
│ │ ├─┬ [email protected]
│ │ │ └── [email protected] 
│ │ └─┬ [email protected]
│ │   └─┬ [email protected]
│ │     └── [email protected] 
│ └── [email protected] 
└─┬ [email protected]
  ├── [email protected] 
  ├─┬ [email protected]
  │ └── [email protected]  deduped
  └─┬ [email protected]
    └── [email protected] 

Error:

Bundling 'index.android.js'
  Transforming modules  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░  99.3% (823/826)...(node:30460) UnhandledPromiseRejectionWarning: UnableToResolveError: Unable to resolve module './common' from '/Users/thomasghenry/code/rn_apps/feathers_client/ptm_feathers/node_modules/debug/dist/debug.js': Directory /Users/thomasghenry/code/rn_apps/feathers_client/ptm_feathers/node_modules/debug/dist/common doesn't exist
    at Promise.resolve.then (/Users/thomasghenry/code/rn_apps/feathers_client/ptm_feathers/node_modules/react-native/packager/src/node-haste/DependencyGraph/ResolutionRequest.js:445:15)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
(node:30460) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1653)
(node:30460) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate thBundling 'index.android.js'
  Transforming modules  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░  99.8% (825/826)...

It looks like it can't find common. It is indeed not there.

$ ls -ltrah /Users/thomasghenry/code/rn_apps/feathers_client/ptm_feathers/node_modules/debug/dist/
total 28K
-rw-r--r-- 1 thomasghenry staff 26K Oct 26  1985 debug.js
drwxr-xr-x 3 thomasghenry staff  96 Sep 11 17:36 .
drwxr-xr-x 9 thomasghenry staff 288 Sep 11 17:36 ..

(1985 though?)

[Qix-]

@ThomasGHenry as I linked in your other post, please move this to #606. Your post doesn't help me debug the problem.

Is the intention for me to fiddle with the debug version in dependencies that I know nothing about?

No, of course not. That would be silly. However, I can't help you unless you help me by:

1. Posting in the correct issue (#606)
2. Posting _reproduction steps_ or _reproduction code_ as I cannot reproduce this on my end.

[realityking]

@Qix- I just tested this on a repo with several indirect dependencies on debug. Nuking both the node_modules folder and package-lock.json it actually installs debug 3.2.4 when running npm install, printing the deprecation message in the process.

For an easy test of this behaviour, create a new project and run npm install --save madge

Given how common debug is in the node ecosystem and how many packages will want to continue supporting Node.js 4, that is a problem.

Possible solutions:

• Undeprecate 3.2.4
• Release the code from 3.1 as 3.3
• (My preference) Release 02b9ea9fd7ec95c42de47da13b4b6bb8e50025d8 as 3.3 [last commit before Node.js 4 was dropped from the support matrix)

Edit: Forgot to mention, this is using npm 5.6.0

[Qix-]

how many packages will want to continue supporting Node.js 4

They shouldn't. Node 4 is not supported anymore. It won't even receive _maintenance_ updates anymore. It's a liability to do so.

We can only support versions going back so far. Otherwise, no progress can be made.

3.2.4 should work for Node 4 users. In most cases, npm will download 3.1.0. Both are compatible with each other.

3.2.4 shouldn't be downloaded anymore as npm has them as deprecated.

$ npm i debug@3
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

+ [email protected]
updated 2 packages and audited 895 packages in 1.326s
found 0 vulnerabilities

The releases should be okay as-is. Are you facing a specific problem aside from a deprecation notice? I'm okay with users of Node 4 seeing deprecation notices. They are, after all, deprecated.

[realityking]

They shouldn't. Node 4 is not supported anymore. It won't even receive maintenance updates anymore. It's a liability to do so.

I agree but there are plenty of developers in the ecosystem who will disagree with us.

3.2.4 shouldn't be downloaded anymore as npm has them as deprecated.

I just looked through the npm documentation and couldn't find any reference to this behaviour. It also doesn't match my test above. Are you sure that is npm's behaviour?

I'm okay with users of Node 4 seeing deprecation notices. They are, after all, deprecated.

But I'm not a Node 4 user. I'm a node 8 user, I just happen to have dependencies in my chain which support Node 4. I even have some indirect dependencies on debug 2.6 since those packages support even older Node versions. (Express comes to mind here)

IMHO that shouldn't cause a deprecation warning if there's nothing wrong with the specific version if the package.

I really appreciate that you're reviving debug but this issue is going to cause tremendous churn in the ecosystem. Debug has over _20000_ dependendents.

[medikoo]

3.2.4 shouldn't be downloaded anymore as npm has them as deprecated.

npm update of npm v4 (and many devs still use this, as v5 and v6 is known to have plenty of bugs), installs v3.2.4

Generally best move would be to publish v3.1 as v3.2.5 (as non deprecated), and that should address all possible buggy scenarios.

[Qix-]

I just looked through the npm documentation and couldn't find any reference to this behaviour. It also doesn't match my test above. Are you sure that is npm's behaviour?

Look at the code block in https://github.com/visionmedia/debug/issues/603#issuecomment-420434656. At least in some places, npm behaves that way.

IMHO that shouldn't cause a deprecation warning if there's nothing wrong with the specific version if the package.

Node 4 is deprecated. Packages that are still around for that version of Node are most likely buggy and riddled with vulnerabilities. Users should be actively moving away from old versions of Node.

I really appreciate that you're reviving debug but this issue is going to cause tremendous churn in the ecosystem. Debug has over 20000 dependendents.

I disagree, and I'm well aware of how many dependents debug has. That doesn't mean it should remain in the stone ages. I'm a maintainer of chalk and we do just fine dealing with progressive releases and keeping this quite up to date - and we're in the same ballpark of dependents/downloads.

There's simply no excuse anymore.

---

@medikoo 3.2.5 is published and will remain un-deprecated. Everything should be fixed.

[realityking]

@medikoo 3.2.5 is published and will remain un-deprecated. Everything should be fixed.

Thank you!

[kevinxh]

Hi! We have a few "legacy" node 4 projects that uses library "connect": "2.4.5", recently when we run the projects we get error:

/Users/kevinhe/.nvm/versions/node/v4.8.7/lib/node_modules/mobify-client/node_modules/connect/node_modules/debug/src/node.js:132
    let val = process.env[key];
    ^^^

SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:373:25)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (/Users/kevinhe/.nvm/versions/node/v4.8.7/lib/node_modules/mobify-client/node_modules/connect/node_modules/debug/src/index.js:9:19)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)

I'm not familiar this breaking change issue, but we are currently still suffer as of date 2019.06.10.

I totally understand Node 4 is deprecated, but due to business reasons, it's hard for us to migrate hundreds of Node 4 projects. I'm wondering if there is a way for us to fix this issue without updating dependency versions?

[Qix-]

Yes, update your version of node or pin to v3? Youre using an unsupported version of Node and exposing your users to potential security risks. The current LTS, if I'm not mistaken, is v10.

Further, the versions of debug other packages choose to use is out of my hands.

If you need ES5, use Babel.