RFC: Minimum PHP version for highlight.php 10

[allejo]

It looks like highlight.js v10 is in the planning. This means per our BC policy, we'll be removing any deprecated functionality once we release a v10 of this project.

Additionally, I would like to get feedback from the community about the minimum PHP version for the next major release of this project. I typically align my projects with the LTS versions of other major projects:

• Symfony 3.4 LTS (EOL: November 2021) PHP >= 5.5
• Symfony 4.4 LTS (EOL: November 2023) PHP >= 7.1
• Laravel 5.5 LTS (EOL: August 2020) PHP >= 7.0
• Laravel 6 LTS (EOL: September 2022) PHP >= 7.2
• Debian 8 LTS (EOL: June 2020) PHP >= 5.6
• Debian 9 LTS (EOL: June 2022) PHP >= 7.0
• Ubuntu 16.04 LTS (EOSS: April 2021) PHP >= 7.0
• Ubuntu 18.04 LTS (EOSS: April 2023) PHP >= 7.2
• WordPress PHP >= 5.6

Given this information, I'd like to hear from the users of this library as to what PHP version they're using and if it's an older version, why they're still supporting it. There's still time until highlight.php v10 but the more information I can get early the better.

There's nothing in this library that critically relies on a feature in PHP 7.x, so I don't mind keeping the minimum PHP 5.x but if there aren't enough users using an EOL'd version of PHP, I won't bother with it either.

Related

• Version 10 Breaking Changes  highlightjs/highlight.js#2273

[markseuffert]

We're supporting PHP 5.6 and PHP 7.x ... no specific reason, just backwards compatibility for now.

[joshgoebel]

Are all your languages just static/"compiled" versions of our original JS grammars? That should be interesting once we start adding dynamic callbacks and such things that execute actual Javascript code during the parsing (inside the grammar) to allow for smarter parsing. I'm not sure how you'd handle that auto-magically.

Dynamic grammars have also been discussed, where the grammar can self-configure at run-time.

hljs.registerLanguage("fortran", fortran, {version: "77"})
// vs
hljs.registerLanguage("fortran", fortran, {version: "90"})

Though I suppose you could do that at build time and just save static "fortran77" and "fortran90" builds, or something. Technically this is already possible, it's just not easily exposed. I know at least one of our 3rd party grammars uses that ability.

[joshgoebel]

There are breaking changes, but so far most of them are just us shifting things around that might change people using the library in very specific ways or who have hard coded file locations, etc... Someone just using the default build on a web page might not nothing, but people doing funky things with the npm library and building custom derivatives are more likely to need to make a few adjustments.

The only pure removal I saw so far is:

• remove restoreLanguageAPI (version 9 compressed languages are not compatible with version 10)

I'm not sure if you support the "compressed" version of the grammars anyways since you package them all yourself as JSON files.

---

And things like our build system changes or Javascript version requirements aren't really going to affect you at all I wouldn't think. :-)

[allejo]

Are all your languages just static/"compiled" versions of our original JS grammars? That should be interesting once we start adding dynamic callbacks and such things that execute actual Javascript code during the parsing (inside the grammar) to allow for smarter parsing. I'm not sure how you'd handle that auto-magically.

Correct, all of our languages are "compiled" versions of the original JS grammars. To be completely honest, I'm not sure how this project is going to handle callbacks; we'll have to explore options once the highlight.js v10 API is defined.

Dynamic grammars have also been discussed, where the grammar can self-configure at run-time.

hljs.registerLanguage("fortran", fortran, {version: "77"})
// vs
hljs.registerLanguage("fortran", fortran, {version: "90"})

Though I suppose you could do that at build time and just save static "fortran77" and "fortran90" builds, or something. Technically this is already possible, it's just not easily exposed. I know at least one of our 3rd party grammars uses that ability.

@yyyc514 Which 3rd party language do you know of using this ability? I have issue #58 which is exploring support for 3rd party languages.

I'm not sure if you support the "compressed" version of the grammars anyways since you package them all yourself as JSON files.

Yea, this didn't really seem to me to be beneficial for this project so we don't really have this.

[joshgoebel]

Which 3rd party language do you know of using this ability?

https://github.com/highlightjs/highlightjs-shexc

[allejo]

Since there are no critical features from PHP 7 required to maintain this library. At the moment, highlight.php 10.0.x is planning on having PHP 5.6 be the minimum requirement since WordPress reports that PHP 5.6 is still being used significantly at the time of writing this.