[Discussion] Is an ES5 build/distribution necessary?

[puzrin]

Editor: Adding some answers here at the tope for anyone else who finds this with Google.

If you're using the library as a direct dependency

There is no need for an ES5 build if you're using the library as a first-order dependency. Just build us separately and drop the web build of the library directly into your project. (either as a separate JS <script> tag) or concat it to the end of your monolithic build. Simply:

# from any unix shell
cat highlight.min.js your_monolithic_js_bundle.js > final_build.js

And of course you can do this easily with a build system as well.

If you're using Browserify

Evidently you can simply enable the global option. [more details would be helpful]

---

The original issue:

Ref: https://github.com/highlightjs/highlight.js/issues/2501

As you know, v10 announced stop support of IE11. But, indirectly, published releases become not es5-compatible any more. If you have cases where es5 (babelified src) is still needed (except IE11) - please post here details.

Support of es5 may be considered for prolong if a lot of demand exists.

---

[Maintainer]: I know it's mentioned above, but just to be very clear this issue is NOT about IE11 (or other legacy browsers) support. The ship has sailed on that. This is only about whether there is value in proving a pre-build ES5 distribution to use with picky/older build systems that haven't caught up to ES6 yet.

[joshgoebel]

Also, I'm very curious how others have solved this problem (if anyone has it) as I assume there are indeed ways for consumers of our NPM library to run babel against it themselves during their build process and ES5-ify it. I'm not sure how hard or easy that might be...

[joshgoebel]

If it's the main blocker, i could try to help.

To be clear right now the main blocker is that this does not seem necessary and I'm imagining there are other reasonable solutions (which I hope someone will come along and mention). Not to mention that if browserify wants to remain relevant I'm sure it will be adding proper ES6 support - am I mistaken? So it only seems a matter of time until this resolves itself - without requiring any time on our side.

@puzrin Have you filed an issue with browserify on this or does one already exist? A link to it here would be great.

[puzrin]

@puzrin Have you filed an issue with browserify on this or does one already exist? A link to it here would be great.

No. I have no concrete suggestions to solve for them.

Ref: https://github.com/babel/babelify#faq

[joshgoebel]

No. I have no concrete suggestions to solve for them.

Well isn't the problem simply that their build pipeline needs to properly support ES6 code? This seems like an issue that should be filed against their project. What am I missing?

This is one (of many) reasons we moved away from our prior build system... it could not understand ES6 code, so it was a poor choice since we're now using ES6 code in the project.

[puzrin]

Well isn't the problem simply that their build pipeline needs to properly support ES6 code? This seems like an issue that should be filed against their project. What am I missing?

They have option to force babel for all sub-deps (see faq link). But that increases build time. I have a lot of deps, but only hljs has such "problem".

This is one (of many) reasons we moved away from our prior build system... it could not understand ES6 code, so it was a poor choice since we're now using ES6 code in the project.

IMO this things are not related anyhow. Right now you can bundle multiple esXX versions, with almost no efforts. May be later, if you decide use advanced es6 feature this may change. But right now drop of es5 looks very strange decision.

[joshgoebel]

But right now drop of es5 looks very strange decision.

To be clear we didn't "drop" ES5 - so much we upgraded from ES5 to ES6. We've always supporting a SINGLE ECMAscript standard - now we simplify support ES6 rather than ES5.

But that increases build time. I have a lot of deps, but only hljs has such "problem".

Sounds like it shouldn't increase build time much if it's only library that needs to be "down-sampled". And with a good build system there should be ways to cache this as well...

Well isn't the problem simply that their build pipeline needs to properly support ES6 code?

You didn't answer this... our build system (Rollup) works just fine with ES6 code natively... what is the problem with Browserify that it can not bundle ES6 modules?

[joshgoebel]

@puzrin Please see issue I opened against browserify...

browserify itself does support modern syntax through acorn-node but some transforms may not.

Perhaps it's your transforms, not browersify that's the problem... or you need to install acorn-node?

[goto-bus-stop]

acorn-node is used internally by browserify so there is no need to install it separately.

From the other issue it sounds like the actual problem is not syntax support in browserify but the fact that it has no simple way to transpile a particular dependency. You can combine https://www.npmjs.com/package/tfilter and babelify to do that. Babel itself filters out node_modules files at some stage I think and needs some configuration to avoid that, but I don't remember what exactly.

[joshgoebel]

From the other issue it sounds like the actual problem is not syntax support in browserify but the fact that it has no simple way to transpile a particular dependency.

Why would our library need to be transpiled at all if the syntax is not a problem or browserify?

[goto-bus-stop]

Only if you do want to target old browsers, or if you are using outdated transforms.

[puzrin]

You didn't answer this... our build system (Rollup) works just fine with ES6 code natively... what is the problem with Browserify that it can not bundle ES6 modules?

You ask me question, that requires dig browserify docs or debug existing app. That's a bit against of my goal. I don't keep in head everything. I have big project, with es6 cjs sources + es5 deps, and with es5 output after bundler pipeline. It's ok for my need, and i would not like to change it until possible.

[joshgoebel]

@puzrin Looks like this is something you'll need to fix yourself. Seems clear this is specific to your project (or at least fixable if you decided to put in the time) and not truly an issue with browserify OR our use of ES6... of course it's alway great if someone else does the work for you, but unfortunately in this case it won't be us.

Also: You can always build HLJS separately and just use the pre-built JS file outside of your complex build process completely - or just have your build process "concat it" (without any processing). Most build pipelines have an easy way to do that. So it seems there are numerous ways to solve this easily - even if not the exact way you'd like to see it solved.

Good luck.

Closing this issue.

[ljharb]

@joshgoebel it is, quite simply, unsafe to transpile code one didn't author, so by your choice to support ES6 and not ES5, you have effectively blocked anyone from using your library in an engine older than your native syntax.

I would strongly urge you to transpile your package to ES5 before publishing if you are interested in those users being able to use your library.

[joshgoebel]

@ljharb Curious, how is it "unsafe"? I'm not sure I was recommending that in any case. We no longer support any ES5 browsers so moving to ES6 on the client-side made complete sense. I offered several suggestions for getting around this persons legacy build system that they don't want to fiddle with. Simply loading the JS file separately or "concat"ing it "as-is" to a larger build should work just fine for any browsers we still support.

[ljharb]

@joshgoebel transpilation is not 1:1, there's all sorts of caveats and edge cases that only the author of the code is qualified to determine if they don't apply.

You're certainly within your rights to drop support for ES5 engines - but please do so knowing that it is effectively impossible for anyone who supports those engines to use your library any further.

[john-doherty]

Gutted you've dropped support for ES5. I just added your code to a project that has a gulp build system, the es6 code in your lib breaks that. How would i build an ES5 version of this?

[joshgoebel]

No idea - but I'm 99% sure that's the wrong question. We no longer support ES5 browsers and JS run-times. If Gulp does not support ES6 easily I'd suggest perhaps just dropping the web build of the library directly into your project (in its entirety). IE:

• Build it first with ./tools/build browser ...
• Take the distributable and plug it into your build system with some sort of concat plugin (to append it to your build)

Of course you'd likely automate this... (or just make bumping the dependency a more manual task). Of course you could also choose to just serve the highlight.js asset separately.

Even a simple one-line concatenation can work:

cat highlight.min.js your_monolithic_js_bundle.js > final_build.js

[joshgoebel]

do so knowing that it is effectively impossible for anyone who supports those engines to use your library any further.

This is very untrue and also misleading as there are any number of ways to include our library still (I just mentioned one to @john-doherty)... it's definitely still doable, perhaps just a tiny bit more elbow grease or perhaps none at all (if you're willing to just load the asset separately as MANY websites do - including some very large ones).

[ljharb]

That's only the case if highlight.js is a direct dependency (and not a transitive one), and also if your build process allows for that kind of alternative inclusion (most modern ones don't; everything comes in as a normal npm dep, and is run through a bundler).

It's certainly doable - it's computers, we can make them do anything that can be done - but it's effectively impossible because it's not going to be practical to safely do so in the general case.

[joshgoebel]

and also if your build process allows for that kind of alternative inclusion (most modern ones don't; everything comes in as a normal npm dep, and is run through a bundler).

I'll qualify here: any build process/system that can't easily concat two files together is already a lost cause. :-) I know for sure Gulp can easily do this because I've done it before. If the complaint is really "but i have an extra build step" (Highlight.js) then yes, you would (or you could vendor the library as a static file) - but this should be an easy thing to automate in a reasonable build systems. If not I'd argue the build system is deficient.

That's only the case if highlight.js is a direct dependency (and not a transitive one)

This is a much better a point and arguable a bit harder to solve (I'd imagine). I imagine it would require a small patch to whichever dependency pulled in HLJS to use a the global ES6 version instead. Obviously would be situation dependent.

---

My opinion here remains the same. This seems to be a niche problem destined to solve itself as ES6 support becomes more mainstream - or people switch away from broken build systems that don't support ES6 (ES2015). It also seems there are ways to do this (with various build systems) just run everything thru Babel, etc, but I don't know about all that. It sounds pretty awful to me to have to do that when your deployment target is a modern browser.

[joshgoebel]

@ljharb Also (to clarify), often it's not even the build system that's at fault but exactly how people have used/extended/customized it (as so often happens with build systems). For example the original poster here was using Browserify but when I posted an issue upstream asking them if they support ES6... they most certainly totally do, but some specific transforms/plugins may not. So I have a feeling the issue here is often specific legacy build pipelines (as implemented by the user) rather than legacy build systems (overall).

ES6 is no longer a shiny new toy anymore. (it seems major browsers have supported it for 4+ years now and counting)

[puzrin]

In browserify i had to enable global option, and that increased build time.

IMO your talks about build systems look like if i start teach you js programming - not very useful and not very relevant.

[joshgoebel]

IMO your talks about build systems look like if i start teach you js programming - not very useful and not very relevant.

Please, no need for rude or disparaging comments. I don't believe I've been disrespectful here. If "abused" came off poorly I've removed it from my comment (and you have my apologies) - I was using it only in the sense I hear it used regularly "use and/or abuse" in various context - not as any form of personal slander.

I've personally used (and perhaps abused) several of the popular JS build systems (Webpack, Gulp, Rollup) on different projects and I've written the build system we use with Highlight.js entirely from scratch (though it uses rollup). I surely do know something about build systems and JS programming. :-) I've certainly never said I know everything.

So far though I feel I've been mostly correct here in my overall assertion:

• There are [various] reasonable solutions here other than us providing an ES5 module.
  (Including SUPER trivial solutions for those using us as a first-order dependency.)

In browserify i had to enable global option, and that increased build time.

So a super easy solution, yet one that does indeed have a small cost. So not "effectively impossible".

[joshgoebel]

@puzrin Out of curiosity which library is it you use that pulls in Hightlight.js as a dependency?

global

Also are you referring to opts.insertGlobals or something else? I'd be curious to look up whichever option you used to solve your problem to learn more about it. If you could point me to some docs on global I'd happily take a look at what it's doing.

[joshgoebel]

@puzrin Also if you could perhaps document your solution here at the top of this issue so that others having the same problem would know how easy it is to solve (with Browersify) that could help someone else using Browserify in the future. I'd do it myself but I don't understand exactly where global is and how you're toggling it, etc.

[joshgoebel]

@john-doherty Are you using Highlight.js as a direct dependency or transitive (a dependency of something else you depend on)?

[puzrin]

Search .global @ https://github.com/browserify/browserify readme. That should be transform flag.

IMO, people, who use certain bundlers & set of options know very well context of their projects (what they do and why they do). I could understand es5 drop if you just don't like it (i can understand personal opinion, even if i disagree). But repeating longreads about bundlers look out of scope, IMO.

[joshgoebel]

Ah, yes:

If opts.global is true, the transform will operate on ALL files, despite whether they exist up a level in a node_modules/ directory. Use global transforms cautiously and sparingly, since most of the time an ordinary transform will suffice. You can also not configure global transforms in a package.json like you can with ordinary transforms.

I'm not sure what "ALL" is there, but that does sound a bit excessive... making me wonder why we don't quality for "most of the time an ordinary transform will suffice". You'd obviously prefer for a way to target just us (or barring that) whatever dependency is pulling us in. Hard to comment further without knowing details. I obviously (and no argument) do not understand your full build process. :-) I assume it's closed source since you haven't linked to it for reference?

I'll also suppose (since you did not answer) that you are not using us as a direct dependency - since if you were then you wouldn't need global at all and the impact on the overall build process should be insignificant (we build in seconds). It certainly quite common for someone to use us as a direct dependency which is why that first sprang to my mind.

I'd take a look at exactly HOW we're used as a dependency if you'd share which library is pulling us in.

But repeating longreads about bundlers look out of scope, IMO.

I was only trying to help the latest person. If I didn't think what I mentioned was relevant I wouldn't have mentioned it. But we're all certainly entitled to our opinions. :-)

[joshgoebel]

Out of curiosity regarding "Exactly what is the problem here" (since I don't think I've ever been shown a reproducable example) I just threw a small example together with lowlight (which pulls in Highlight.js as a dependency) and Browserify... pretty much:

npm init ...
npm install lowlight
echo -e 'var hljs = require("lowlight")\nconsole.log(hljs)' > main.js
browserify main.js -o bundle.js

Built and worked as expected with no issues. Now I'm sure your build system is a lot more complex that this trivial example, but at a glance it's hard for me to see how ES6 doesn't work with Browserify. I'd really be curious to see an actual failing example (or known specifically which transform is not ES6 compatible) since I'm still confused as to what the actual bottom-line issue is.

So it just bugs me to hear "my build system Browersify doesn't support ES6" because that seems to be a clear misstatement of the actual problem which seems to (at the very least) be much more nuanced.

[puzrin]

Browserify works with es6. But babel (via babelify plugin), without .global - not applied to deps, if those have no inividual configs. It's difficult to "degrade" code syntax to desired level.

[joshgoebel]

Obviously I'm missing something as it's still unclear to me why our code needs to be "degraded" at all. Our library should not need to be run thru Babel at all. So if we're "untouched" as a dependency, then I don't see the issue. That should be perfectly "OK".

If the babelify plugin is "all or nothing" that seems like a clear problem that needs addressing with the plugin. Having to process all your source thru babelify even if large portions of that code are already at a workable ES* level seems like a very annoying requirement.

I'd wager there is an alternative solution than global to be found, but if global is working for you, then that's great.

[puzrin]

As i said, i'm not sure your opinion about "how hljs should be bundled" can be helpful for my case. I don't keep all details in my head, and remembering takes notable time. Can't do it "just for fun".

I'd wager there is an alternative solution than global to be found, but if global is working for you, then that's great.

It works, but cold start now takes 50s instead of 30s. Not fatal, but unpleasant (and just because of single concrete pakage).

[joshgoebel]

Unpleasant indeed. I'm pretty sure also unnecessary. I just don't think either of us knows the right answer yet. 🙁 I'm confident the answer is not an ES5 module. Unless you have a very unusual use case.

If you end up working on it again in the future and have the time to come back here and explain more context (while it's still in your head) we'll be here. 

[puzrin]

Construcive discussion expects profit for both sides :). For my side profit could be in adding es5 build back. But since that will not going to happen...

[joshgoebel]

Based on years of client experience I never solve the stated request... I focus on underlying problems. In my experience 95% of the time the stated request/desired solution is wrong (or incomplete). Most often the underlying problem has not been correctly understood. 

Correct, right now there's no intention to provide an ES5 build (just to run on ES6 runtimes). I'm unpersuaded anyone needs that build - including you. 🙂 It would not surprise me if the solution for Browserify is a small amount of JS code to customize the build. Yet it's clear I don't yet understand the underlying problem so that makes it harder to help. 

If your target is an ES6 runtime then there's no need to transpile our library and there should also be no need for an ES5 version. It's just the wrong solution. Makes no sense. 

I assume your profit would be your build times returned to 30 seconds. 🙂 But if your done discussing that's fine. 

[joshgoebel]

@john-doherty

I just added your code to a project that has a gulp build system, the es6 code in your lib breaks that.

It might also help if you clarified your problem a bit more. How exactly does our code break the build? Are you saying that Gulp simply doesn't support ES6 code? Can you show us your Gulp set up?

Edit: I've used Gulp with ES6 code before without issue.

[ljharb]

Most build processes do not transpile third-party code, because it's not safe to do that. For example, https://unpkg.com/browse/highlight.js@10.3.2/lib/core.js has arrow functions - it seems like the way you are using them, they're just syntactic sugar, so they'd be safely transpilable, but arrow functions themselves are not safe to naively transpile. They lack a .prototype property, which is both impossible to fake and affects things like using new on them.

Any build process that blindly transpiles third-party code is being reckless and risking breakage to the most vulnerable of users, those using older browsers/engines. It's certainly something that can be opted into, but it is not safe and it's not reasonable to expect anyone to do it. In other words, if you want to drop support for runtimes that, for example, lack arrow functions, please accept that you are forcing your consumers to do the same, because it's simply not practical to audit the entire dep graph and determine whether transpiling is safe, since the vast majority of transpilation is not 1:1.

[puzrin]

https://github.com/highlightjs/highlight.js/blob/master/.eslintrc.js#L17

Linter allowed settings are es9 (es2018), not es6.

npx browserslist "defaults, not dead, not ie 11" - that sill require babel settings less than es9.

[joshgoebel]

@ljharb Did you read my last few messages? I'm not asking anyone to transpile us... I'm suggesting there should be zero reason (or need) to do so. We only support recent versions of Node and green-field web browsers - all ES6 run-times. Most anything in the past few years works just great. What puzrin was seeming to suggest originally is that he only needs an ES5 build to make his build system happy (because it chokes on ES6), but then when he then starts talking about running us thru Babel I get lost.

but arrow functions themselves are not safe to naively transpile. They lack a .prototype property, which is both impossible to fake and affects things like using new on them.

Out of curiosity... how does that make this "unsafe"? Or are you simply saying because the behavior (in edge cases) can't be 100% guaranteed that it's therefore "unsafe"? I can't think of why someone would call new on an arrow function or access prototype for that matter... perhaps a complex system doing introspection of objects could fail in weird ways? I'm sure there are edge cases, I'm just not thinking of them off the top of my head. I agree

If someone were going to transpile us they'd obviously they should take the security concerns into mind, but I just don't see why anyone would...

if you want to drop support for runtimes that, for example, lack arrow functions, please accept that you are forcing your consumers to do the same

We've been VERY clear about that. Do only support ES6 run-time environments, and the library we publish therefore is free to use ES6 features as it sees fit.

[joshgoebel]

Linter allowed settings are es9 (es2018), not es6.

Indeed. Though this does not require an ES5 build. Though it's potentially a valid reason one could want an ES6-only build. We currently only actually use ES6 code (AFAIK), but just looking now I'm also not sure I have any issues with us making the minimum requirement ES2018. All the desktop targets we support seem to well support ES2018 as well (at the least the features we would use, I'm not sure about FULL support). I'd have to take a closer look at mobile first.

npx browserslist "defaults, not dead, not ie 11" - that sill require babel settings less than es9.

It would be helpful if you mentioned specially which environment you're trying to target - which browser are you actually worried about? Desktop? Mobile? (or do you not really have one in mind?) I think you're supporting a wider range of browsers than we support... Off the top of my head it'd be something more like:

      "targets": {
        "edge": "79",
        "firefox": "60",
        "chrome": "67",
        "safari": "12",
        "node": "12.0"
        }

An ES2018 vs ES6 discussion might be a much more relevant topic. :-)

[ljharb]

@joshgoebel yes, but in reality, there is a lot of need to do so. You don't have to agree, of course! However, anyone whose business requires them to support these browsers - which is a great many of us - simply can not use your library without it providing an ES5 build. I agree that anyone targeting an ES6 runtime doesn't need an ES5 build - the problem is that most of us absolutely must target an ES5 runtime, and forgoing the revenue from those users is simply not a viable option.

So, again - not providing an ES5 build screws over your users who must target ES5 runtimes. If that's the choice you're sticking with, so be it, but please do not pretend you're doing anything less than that.

[joshgoebel]

I don't think we're doing any pretending. We very purposely chose to drop support for IE11 and other non-ES6 browsers. We simply don't have the time (or desire) to support them or their weird quirks. We're supporting 95-98% market share (and growing of course) according to caniuse.com. https://caniuse.com/es6

I can certainly sympathize with business requirements, but someone who needs to support IE11 should probably look for a different highlighting library - or perhaps maintain a small fork (or sponsor one) where they are then responsibility for old browser compatibility and breakage, etc.

So, again - not providing an ES5 build screws over your users who must target ES5 runtimes.

Just curious, is there a specific runtime you're thinking of other than IE11 when you say this?

The fact that this issue (and dropping support for IE11) have received so little interest leads me to believe we're making a reasonable choice for most of our users. Version 10 was released at the beginning of the year and only one or two people have spoken up about IE11 or older browser support.

[puzrin]

It would be helpful if you mentioned specially which environment you're trying to target - which browser are you actually worried about?

Browserlist readme advices to worry about npx browserslist "defaults". It costs nothing to wrap hljs call with try/cach to off for ie11, but customizing bunldle process for single package is boring.

An ES2018 vs ES6 discussion might be a much more relevant topic. :-)

As i said earlier, i find your opinion about using bundlers in outer projects too obtrusive, and discussing such things - not optimal time spend to solve introduced problem.

[joshgoebel]

Browserlist readme advices to worry about npx browserslist "defaults".

I don't know about some of these mobile? options but if you remove IE11 from that list I think there is a lot of ES6 support there. Everything I recognize at least is quite new (all the major browser players, etc) and supports ES6. Opera Mini seems a no and both Baidu & KaiOS are listed as "some compatibility". All of those being < 1% usage.

It costs nothing to wrap hljs call with try/cach to off for ie11, but customizing bunldle process for single package is boring.

Not sure I follow what you're suggesting here.

Linter allowed settings are es9 (es2018), not es6.

Just to confirm the existing codebase is all ES6 [no ES2018 code according to linter] (and likely to stay that way for the near future). So if you were only running us thru Babel because of that mention of ES2018 in the eslint config, you can stop now. :)

[puzrin]

For clarity - i don't think you MUST support es5 build. I solved my needs silently, without BS like "you don't understand how opensource works and should not ignore needs of project users". I only don't like mutating context of issue into direction "such demands are silly" (with meaning "silly" demands are written by "silly" users).

Not sure I follow what you're suggesting here.

I just suggest to be more gently with public statements :). What you feel with this is ~ the same as i feel with your posts about "how bundlers should be used" :).

I don't know about some of these mobile? options but if you remove IE11 from that list I think there is a lot of ES6 support there. Everything I recognize at least is quite new (all the major browser players, etc) and supports ES6.

1. People may not wish to remove IE11 for Babel. They may wish to remove highlighing for IE11.
2. I don't remember why, but with npx browserslist "defaults, not dead, not ie 11" Babel still produces some pre-ie6 code.
3. Nobody is happy to change stable bundling process, if es5 output is ok.
4. Personally, i don't like need to spend time for explaining such things. And without explaining, you declare demands as "not clever". It's normal, if you don't know something. But it's not normal to declare everything else ancient in advance.

Just to confirm the existing codebase is all ES6 [no ES2018 code according to linter] (and likely to stay that way for the near future). So if you were only running us thru Babel because of that mention of ES2018 in the eslint config, you can stop now. :)

See above. I don't like idea to customize bundling process for every specific package. That's not good for my maintenance expectations.

[joshgoebel]

without BS like "you don't understand how opensource works and should not ignore needs of project users".

Except you just kind of went and said it now... I'd suggest "ignore" is a very strong word. Everyone on the core team volunteers their time to maintain this project. We support 95-98% of browsers commonly in use today. I spend a lot of time on this project meeting a LOT of users needs. I'm sorry if you feel your projects needs have been ignored, but let's not overly generalize.

I only don't like mutating context of issue into direction "such demands are silly" (with meaning "silly" demands are written by "silly" users).

I don't think I used the word "silly" anywhere. I think the language barrier here hasn't helped us any... it's possible you're reading tone or intent into what I'm writing that simply is not there. I tend to be very plain spoken.

What you feel with this is ~ the same as i feel with your posts about "how bundlers should be used" :).

I don't believe any of my remarks about bundlers devolved into personal insults. It probably would have helped if I understood your original goal better (way back when). To me the only non-ES6 browser that even exists (and possibly worth caring about) is IE11... If that makes me dumb, then so be it, but the market share of any others (overall) seems so close to 0 as to almost be a rounding error. So your talking about ES5 apart from IE11 really just went over my head (my apologies). For a long time I thought you wanted to build ES5 just because your build system mandated it for some strange reason - which made very, very little sense. :-)

Secretly I wondered if you really still just wanted IE11 support (else why compile to ES5? lol)... but now in re-reading it's clear what you were really saying was "Can I still use this in all my other ES5 browsers, just not IE 11?" To which the answer is still no, the market share is just too small to make them worth supporting. Without using or knowing anything about those niche browsers it's simply impossible to make sure users would have a great experience. So along with IE11, they are also now unsupported.

People may not wish to remove IE11 for Babel. They may wish to remove highlighing for IE11.

I wasn't being literal. I was only pointing out that I think most the browsers on that list (with any real general usage) already support ES6, with the exception of IE11. If you were able to drop your IE11 and Opera Mini requirements you might be able to get away with an ES6 build. (not sure, but maybe)

Nobody is happy to change stable bundling process, if es5 output is ok.

Sure, if you're happy with 50s cold start instead of 30s cold start then I suppose it's "ok". Like most things, it's about tradeoffs. In this case the simple "one line fix" doubles the cold start time... vs a slightly more complex bundle that would keep the fast cold start.

And without explaining, you declare demands as "not clever". It's normal, if you don't know something. But it's not normal to declare everything else ancient in advance.

I think I've explained a lot... perhaps I missed a question? I also don't see where I've used the word "clever" anywhere. And not sure what I've declared ancient... ES5? Generally, for 95-98% of browser share it is... though to be clearer relevancy might be a better metric than age.

[joshgoebel]

@puzrin You might also be interested in https://github.com/highlightjs/highlight.js/issues/2756. It's only a matter of time until we're using ES6 features you can't transpile to ES5 at all... and then you're looking at maintaining your own fork of the library... and that's also why we don't officially support ES5 anymore - it's about to potentially get much harder to do so. Lack of time, lack of team interest, lack of real demand, tiny (and shrinking) market share, and we know that we're likely to break it in the near future anyway.

You're welcome to transpile it as long as you can (if that works) - we certainly can't stop you. But we didn't randomly drop support for ES5. It was considered and it was a signal of where things are headed... so while transpiling is working for you right now I'd be spending some time planning your next move...

If IE11 (and other ES5) support is mission critical for you I'd seriously consider looking at https://prismjs.com/ which so far seems interested in IE11 support. Nope, never mind, they are looking to drop IE11 (and likely ES5) support soon as well. https://github.com/PrismJS/prism/issues/1578

[puzrin]

Except you just kind of went and said it now... I'd suggest "ignore" is a very strong word. Everyone on the core team volunteers their time to maintain this project. We support 95-98% of browsers commonly in use today. I spend a lot of time on this project meeting a LOT of users needs. I'm sorry if you feel your projects needs have been ignored, but let's not overly generalize.

Again, i'm ok if you ignore demands of es5. I'm no ok HOW you do that. Probably, due language barrier i can't express my thoughts good enough.

I don't think I used the word "silly" anywhere. I think the language barrier here hasn't helped us any... it's possible you're reading tone or intent into what I'm writing that simply is not there. I tend to be very plain spoken.

Since i have low telepathy skills, i react not to what you think, but how i understand what i read :). From my point of view, package demands could be isolated. Propagating those to app requirements (discussing bundlers) is out of scope (IMO).

People may not wish to remove IE11 for Babel. They may wish to remove highlighing for IE11.

I wasn't being literal. I was only pointing out that I think most the browsers on that list (with any real general usage) already support ES6, with the exception of IE11. If you were able to drop your IE11 and Opera Mini requirements you might be able to get away with an ES6 build. (not sure, but maybe)

IMO operating with guesses is not constructive. There is wide-used browserslist "default" preset. You may not like it or disagree with it. But some people prefer rely on it without care about details of each browser.

Nobody is happy to change stable bundling process, if es5 output is ok.

Sure, if you're happy with 50s cold start instead of 30s cold start then I suppose it's "ok". Like most things, it's about tradeoffs. In this case the simple "one line fix" doubles the cold start time... vs a slightly more complex bundle that would keep the fast cold start.

Those comment was given in context you were giving advices without knowing details and side effets. Any your decisions about hljs are ok. But attempts to "intrude" into outer processes can make someone feel uncomfortable.

No, i'm no "happy" with increased cold start time. I'm just "ok" with it. And if i decide to spend time for improve, i will try multithreading support instead of written recommendations.

And without explaining, you declare demands as "not clever". It's normal, if you don't know something. But it's not normal to declare everything else ancient in advance.

I think I've explained a lot... perhaps I missed a question? I also don't see where I've used the word "clever" anywhere. And not sure what I've declared ancient... ES5? Generally, for 95-98% of browser share it is...

Missed question is, that i had to spend notable time for bundler changes and talks without reasonable needs, from my point of view :). You forced users like me to participated in hljs process, instead of allow make a choice, what kind of bundle to use. That's too pushing. At this moment, bundling to es5 is completely automated process with almost zero cost for you.

[puzrin]

@puzrin You might also be interested in #2756. It's only a matter of time until we're using ES6 features you can't transpile to ES5 at all... and then you're looking at maintaining your own fork of the library... and that's also why we don't officially support ES5 anymore - it's about to potentially get much harder to do so. Lack of time, lack of team interest, lack of real demand, tiny (and shrinking) market share, and we know that we're likely to break it in the near future anyway.

When you use non-transpileable es6 features, that will be another story. But right now you compare "not existing potential features" with really existing "difficulties". IMO such kind of arguments is "black rhetoric" (when goal of discussion replaced with goal to prove "i'm right and you are not").

[joshgoebel]

when goal of discussion replaced with goal to prove "i'm right and you are not"

Obviously you're understanding me wrong. I was simply giving you a clear heads up. You seemed to feel taken by surprise when ES5 was removed (in a major release). So despite you're setup already being unsupported I'm giving you warning now so when things break you can't say it came as any surprise. You could be doing something about that today vs waiting for it to break tomorrow. But obviously that's your decision. :-)

Justifying why we dropped support for ES5 isn't the same as claiming "I'm right". It's possible a different maintainer (in another universe) would have made an entirely different decision. It was the right decision for our team I think, but I don't think it's right or wrong in any universal sense of the word. It simply is what it is.