Version 9 EOL & End of Support (even for security issues)

[joshgoebel]

If you're trying to upgrade your (or someone else's dependencies) you may want to see A note about upgrading dependencies from version 9 version 10 big picture

---

A recent vulnerability has brought the topic of version 9 support back into the forefront. The core team doesn't really have the time or focus to maintain two very different forks of the project. Especially since the version 9 only truly exits to service a tiny audience (IE11, <1% browser share by caniuse.com). We were kind of OK letting it live a bit longer as long as it didn't require any time/effort from us, but that's no longer proving to be the case.

• Many, many issues and bugs have been fixed since the v10 release.
• Many, many new features have been added.
• Many grammars highlight WAY better than they did previously.
• The v10 parsing engine is so much more flexible and reliable.
• There are quite likely numerous vulnerabilities we've fixed along the way without even realizing it.

It's so obvious that v10 and modern browsers (released in the last ~4-5 years) is where we need to be focusing our time, not supporting very old browsers. So if you're still using version 9:

If you aren't supporting IE11 users (or others with very obscure browsers)

You need to upgrade to v10. No question. For 90% of simple cases it's a trivial upgrade. For complex integrations it may be a bit more effort (like most things). https://github.com/highlightjs/highlight.js/blob/master/VERSION_10_UPGRADE.md

If you're supporting IE11 users (or others with very obscure browsers)

Someone truly requiring IE11 support for "enterprisey" projects should perhaps look at Prism.js, which is a great project that still supports IE11. Or perhaps consider maintaining their own private fork of version 10 that supports IE11. This should still technically be possible now (AFAIK) but may prove more difficult as time goes on.

So here is the current plan:

• One last v9 release (security fix).
• That release's release notes will mention the EOL and link to this issue. (and perhaps spew some other output, need to look at what is possible with npm).
• That release itself (and the current v9 release) will both be marked deprecated with a message to upgrade to v10.
• We may mark other prior releases deprecated as well. I'm really curious why more npm projects don't do this. Does anyone know?
• SECURITY.md will be updated accordingly.
• v9 support will then be official EOLed.

So v9 users would want to upgrade to the latest v9 release and then either start working on upgrading to v10 or come up with other plans.

[TimotheDavid]

hello I try to upgrade highlight with npm in node and typeorm but I don't find the folder ... and you don't explain ho to do .... could you explain ?

thanks !

[TimotheDavid]

could you remove the warning when ou install highlight 10.4 : I have already the warning for 9 version .... thanks a lot !

[joshgoebel]

There is no warning on the new version.

[Romakita]

Hello @joshgoebel
Which new version? Because the warning still occur on 9.18.4 and it's a bit aggressive. Especially if the warning comes from a transitive dependency. Can you remove it or change the warning by a simple (and small) depreciation warning please.

Deprecation must be instrumented with npm deprecate: https://docs.npmjs.com/cli/v6/commands/npm-deprecate

Thanks :)

[joshgoebel]

The warning should only be on post-installation.

Because the warning still occur on 9.18.4

Yes, the entire 9 series is no longer supported. We pushed one last update to 9 just so anyone still using 9 would have a window to work on upgrading to 10. It's not intended that anyone use 9.18.14 long-term. The intention is that everyone upgrades to v10.

Deprecation must be instrumented with npm deprecate

Yes, we're deprecating them also. I'm not sure anyone pays attention to those though. I certainly haven't in the past.

[Romakita]

This is exactly the problem. My users install the cli and have an unexpected warning in full page, for a dependency that does not concern them (nor me for that matter). I can fix this problem because the helper-markdown maintainer is responsible to update his code.

I think the right solution is to use npm deprecate instead of a postinstall script!! (it's really a bad practice). By using npm deprecate, you inform npm and many other tools like snyk about the depreciation. Your postinstall script has no benefit for the final user ^^.

See you
Romain

[joshgoebel]

First time doing something like this on NPM. :-) Yes, I understand the issue you're raising now. We need to think about what message we intend to send to users where we are not a direct dependency. Which we didn't take into account (though it seems obvious in hindsight). Are there specific guidelines published somewhere that specifically say "don't do this" with post-install?

It's definitely annoying that the "end user" here doesn't have a direct course of action, but I assume they would bug you, then you would bug upstream, etc... The intended message was supposed to be more of "you REALLY need to upgrade" vs "hey this is old now". I feel like maybe there is no great choice here (or I just don't know best practices). I feel deprecation alone is too quiet and it's possible post-install is too noisy...

I'll talk it over with the team. I assume at this point we'd have to push out yet another release just to remove the warning, right? :-|

[Romakita]

Are there specific guidelines published somewhere that specifically say "don't do this" with post-install?
Not especially, it's true. It's clearly my point of view, and we can agree on the fact that the big warning in post install is a bad use of postinstall ^^

I'll talk it over with the team. I assume at this point we'd have to push out yet another release just to remove the warning, right? :-|
I'm you can take a time to find a proper way to instrument that or just change the message so that it's less intrusive ;)
I understand your point of view though
Thanks

[joshgoebel]

I'm you can take a time to find a proper way to instrument that

Did you have a suggestion other than deprecate?

or just change the message so that it's less intrusive ;)

What level of intrusion would you find reasonable? (just curious) :-)