Update for hightlight.js v10 about lowlight HOT 23 CLOSED

Unfortunately highlight.js 10 removed the APIs that lowlight used to work. It did add an alternative that could be used in the future, but it’s undocumented, beta, and internal. Finally, it has bugs such as infinite loops. So we can’t upgrade yet.

from lowlight.

One problem may be that you are using lowlight directly but lowlight didn’t bump their major version number as well - there by perhaps hiding our (highlight.js) major breaking changes from you. That’d likely be a question for @wooorm

Hard question though because I don’t think the lowlight API changed at all but it’s support for browsers most definitely did.

I think my guidance would likely be that projects like lowlight whose primary dependency is highlight.js should consider probably bumping major versions when we do.

Dependencies of dependencies can lead to all sorts of problems.

from lowlight.

Are you speaking to me? I don't always flag or even recognize such things.

You already have my guidance/thoughts for the future, of course it is your project so you're free to do as you wish. :-)

from lowlight.

Unfortunately highlight.js 10 removed the APIs that lowlight used to work.

Sorry if I'm getting hung up on nuance here, but to me this reads a little unfairly... as if we perhaps removed documented APIs we've long supported. We could have done that in a major release; but we didn't. As far as I know we honor the same documented APIs in v10 that we did in v9.

What we did change was a bunch of our internals... the v10 codebase is significant different than v9 in many ways, yes... perhaps a more nuanced leading sentence:

A lot of the internals [or internal/private APIs even] of Highlight.js changed in version 10 ...

You can see why I want to be explicit about API support (what is "stable") when I read something like "highlight.js 10 removed the APIs that lowlight used to work" - when AFAIK we actually removed no APIs at all. :-)

Finally, it has bugs such as infinite loops.

New release, new bugs. Fixed. :-)

from lowlight.

It did add an alternative that could be used in the future, but it’s undocumented, beta, and internal.

While it is "technically" beta and undocumented but right now there are no real plans to change the Emitter API (the API lowlight needs to hook into) during version 10 - other than perhaps to tweak some function names slightly. If that happened I wouldn't mind making a PR for lowlight to fix the naming. :-) But it should only be a few line patch, if anything.

Even without a "public documented API guarantee" it should be more stable than the APIs used previously were, because it's an API on the edge of a module/class. Making it technically 'external' API in a way... even if we aren't labeling it that way and aren't screaming that from the rooftops. It was designed with care and thought so that it wouldn't need to be changed all the time. :-)

It's lack of documentation is probably more a matter of time and priorities than anything else. If someone wanted to whip up a PR with some great documentation for building custom Emitters I'd be totally open to that.

from lowlight.

It broke ie11 support causing all sort of problems for us. Thanks...

from lowlight.

Sorry you had problems. Version 10 was a major release. That older browsers are no longer supported is clearly documented in the changelog, release notes, and upgrade guide, etc.

And version 9 continues to be usable on IE11.

from lowlight.

Thanks for your answer. I don't know how to solve this though. My customer still uses ie11 (a big corporation). We use tiptap which uses tiptap-extensions, which uses lowlight, which uses highlightjs. I guess I have to force the version of highlightjs somewhere because it breaks the whole bundle under IE11, apparently because it uses "class" (but there might be other reasons). I don't know what I have to modify in package.json to revert to a more compatible version.

And we don't even use the code highlighting feature, so it's a silly situation.

from lowlight.

class and other newer JS features.

Yes you really should likely lock many packages to their current major version in your package.json. Major versions often include breaking changes and should always be approached with care.

I would never bump a major version without reading its release notes and testing first.

Back when I was in charge of the invoicing/accounting system for a company (responsible for millions of dollars) I never bumped -any- library version at all without reading the git diffs, but maybe that was a bit excessive. 🤔

from lowlight.

Yes, it is what I have noticed too. They updated your package version which is a major version with bc breaks without updating their own version correctly.

from lowlight.

@wooorm Probably too late to do anything now but what do you think. When we push v11 one day might it make sense for you to also major version bump? Just to make people take a closer look before upgrading.

from lowlight.

It makes sense to unpublish current version and release under v2 tag since it has major dependency update with breaking changes 🤔

from lowlight.

@golgote @vladshcherbin Can you two lock your dependencies to solve it on your side?

from lowlight.

@wooorm I was just subscribed to the issue but I'd suggest to bump version since there may be more users facing same problem later.

from lowlight.

@vladshcherbin Yes, I saw your recommendation, thanks.

Re the rest of the thread: I don’t like passive aggressiveness. There are several solutions, such as locking packages. It’s been a month, it seems like not many folks experience a problem.

from lowlight.

No, I did not. To clarify, I understand everyone's views here, I hear you, but did not appreciate:

It broke ie11 support [...]. Thanks...

(emphasis mine)

from lowlight.

It broke ie11 support

Well, to be completely clear I broke IE11 support in HLJS. ducks before the fruit is thrown

Agree with you @wooorm, not the best way to start a conversation. Someones gotta share that story about flies and honey... :-)

The other day I almost made a snarky joke about offering someone a FULL refund for the difficulty they've had with this completely amazing free software. But then my better self intervened.

from lowlight.

I apologize for my ironic "thanks" 😬 I am not "passive aggressive" at all, more the active aggressive kind actually, sorry about that 😅 Still I wish js packages could follow some rules not to break bc in minor version bumps. Good luck with your projects.

from lowlight.

I’m going to go with wooorm either didn’t know or just didn’t think to consider the browser compatibility as a BC at the time. IE 11 is after all pretty old software now.

I see JS libraries that push major versions constantly. Requiring every upstream that required them to also version bump wouldn’t be practical at all.

I was surprised at how little feedback we got when dropping it. I was expecting a bit more of a backlash and instead you could hear pins drop for the most part.

from lowlight.

Oh I meant to ask you about your usage of lowlight in the browser as well. Can you share what you’re using it for? If I had to guess I would guess that most lowlight usage is not in the browser but rather on the server side.

That probably also had some impact on this whole issue.

from lowlight.

We use titap, a customizable wysiwyg editor that works with vuejs, which in turn uses lowlight in one of its extensions. We are building an e-commerce solution that allows users to create contents (for example the homepage here: https://boutique.operadeparis.fr/en/) Believe it or not, we have users that still use ie11, it is still popular in French administrations unfortunately. And Microsoft will support it until 2025... 🙄 I ended up building 2 js bundles, one for the frontend without titap and one for the backend. Backend users will be required to not use ie11. All this because of a wrong version number in a package somewhere, but I guess that's how it's done in the javascript community where people want things to move fast.

from lowlight.

I think that to you it's a huge issue (and I totally understand and feel for you), but to many IE11 is already yesterdays news and quite outdated. I made a BIG deal out of it when I released HLJS because I'm a super detail oriented kind of person. In hindsight I probably made too much of a deal out of it - based on how little almost anyone actually cared.

All this because of a wrong version number in a package somewhere, but I guess that's how it's done in the javascript community where people want things to move fast.

I think this is a tough, probably unfair critique. The fact that the JS community works at all with how crazy NPM is has to be some testament to package authors MOSTLY getting things right MOST of the time. It's no surprise that every now and then you have unintentional breakage.

I see packages make major version bumps all the time - it seems impossible that every upstream package should also bump their major version just because one of their dependencies has a bump... so when effectively you have an upgrade like this where the ONLY breakage is for IE11 on the client-side... a browser with overall 2-3% market share... and the fact that for MOST sites using HLJS the breaking even then really only means "now your code doesn't highlight" - but it's still easily readable...

So when it comes to "omg our business has come to a complete standstill" level breakage... out of over a million users of the library, so far we've only had one report - yours. I'd say that's pretty great for a free product supported and developed by volunteers donating their time.

from lowlight.

Folks, to cut a long discussion short:

• I hate that projects break backcompat, I do my personal best to not break things.
• I am sorry your stuff broke, I would’ve preferred it didn’t happen.
• It happened. But you’re the first in a month to notice it, I’m waiting for more folks to voice that they’re hurt before taking action, if that is needed at all.
• I’ve spent years of my free time on open source, making stuff for free, trying to prevent stuff like this from happening. Sometimes I fail. I’m sorry.
• You still should’ve locked your dependencies. Your stuff breaking is on you.
• Here’s our contract: MIT. Notice the things in caps.
• To reiterate, I think this is all unfortunate.

I am locking this because I do not provide customer service for free and the conversation is derailing. If someone also has this problem, please raise another issue.

from lowlight.