Lowering for ES5?

[chowey]

This is an awesome project, by the way!

Do you have any longer-term plans to support ES5? I ask, because this is the only thing preventing me from using esbuild exclusively for all my transpiling needs.

Specifically, I am still required to support IE11, because it still has official support from Microsoft:

Is Internet Explorer 11 the last version of Internet Explorer?

Yes, Internet Explorer 11 is the last major version of Internet Explorer. Internet Explorer 11 will continue receiving security updates and technical support for the lifecycle of the version of Windows on which it is installed. IE 11 is available via Microsoft Update Catalog, Windows Update and Windows Server Update Service (WSUS).

What's worse, the "version of Windows on which it is installed" is Windows 10, which is planned to be the last version of Windows. So IE 11 may not be going away any time soon.

Something like shimport can be used to get ES modules running on IE11, so the only thing missing is ES5 lowering.

Perhaps this is something the community can help with?

[dmichon-msft]

Even without the ability to transpile down to ES5, having the ability to not introduce ES6 code during minification would make esbuild suitable for usage as a replacement for terser on existing ES5-compatible code, which appears to already be a significant performance win. I know that for many projects minification is a significant portion of the ship build time.

I authored this to try to cut down on the time spent in the minification process in large projects; would love to be able to use esbuild as an alternative minifier implementation for even better performance, but I'm stuck needing ES5 support for the time being.

[evanw]

Even without the ability to transpile down to ES5, having the ability to not introduce ES6 code during minification would make esbuild suitable for usage as a replacement for terser on existing ES5-compatible code

This will only happen if you set the target to es6 or above. If you set the target to es5, esbuild will not introduce ES6 code during minification. That flag won't translate ES6 constructs to ES5 because esbuild doesn't have support for that yet, but it will keep ES5 code as ES5 code. Please let me know if you are encountering any errors with ES5 code that unexpectedly becomes ES6 code when the language target is set to es5.

[dmichon-msft]

@evanw, good to know, I guess I misunderstood the issue around arrow functions, since converting function declarations to arrow functions is a pretty common transform when targeting es6. Might be worth mentioning in the docs that you can set the target below es2015, it just won't perform any additional syntax transformations?

[danickinator]

Please let me know if you are encountering any errors with ES5 code that unexpectedly becomes ES6 code when the language target is set to es5.

@evanw the issue that we've come up against trying to target IE11 (we're also locked into supporting it for the foreseeable future) is that IE11 supports a couple of ES6 features - most notably let and const - which will raise an error if esbuild is set to target 'es5'. Unfortunately, targetting 'es6' very quickly generates template literals which IE11 doesn't support.

As a result there currently isn't a target that can safely used to minify code for IE11. An 'ie11' target that was essentially just 'es5' + let/const would be a godsend.

[tooolbox]

Just have to comment how incredibly exciting it is to see the work on lowering template literals to string addition. Three cheers for @evanw !

[HugoDF]

For anyone else like me who was trying to get transpilation to ES5, I've used swc successfully as per this comment: https://github.com/evanw/esbuild/issues/182#issuecomment-646297130 (thanks @evanw ). It's a magnitude faster than Babel.

[mindplay-dk]

As a result there currently isn't a target that can safely used to minify code for IE11. An 'ie11' target that was essentially just 'es5' + let/const would be a godsend.

While fully supporting ES5 is probably considerably more work, this sounds like relatively low-hanging fruit?

This might be a good, preliminary work-around for the "corporate world", where (sadly) IE11 is still the lowest common denominator.

[chowey]

Reversely, adding support for const/let => var is probably the most straightforward lowering that you could ask for.

If it is a comparable amount of work to do that replacement as it is to add a special "ie11" target, then I vote to just do the replacement (s/const|let/var/g or equivalent).

[mindplay-dk]

@chowey is it that simple? let and const have different scope.

[chowey]

You are right, a straight replacement won't work. Here is an example using Babel:

// input
var a, b;
{
  const a = 1;
  var b = 2;
}

// output
"use strict";

var a, b;
{
  var _a = 1;
  var b = 2;
}

[mindplay-dk]

Hm, there's probably a ton of other features required for IE11 too though?

for..of, template literals, default values for parameters, all the new object literal shorthands...

[tooolbox]

Well, template literals are done 😉

[jhsware]

IE11 will reach end-of-life on Aug 17th, 2021, so I doubt supporting it is worth the overhead unless you get it for free. https://www.theverge.com/2020/8/17/21372487/microsoft-internet-explorer-11-support-end-365-legacy-edge

[mindplay-dk]

@jhsware unfortunately, reaching EOL does not mean every user stops using it on that date - as long as there's even 1 or 2 % still using it, most corporate products have to continue to support it. (21+ years of web development made agonizing by IE, so no doubt I'd have been the first to swear it off - sadly, most developers don't get to make that call.)

[chowey]

From the Verge article:

While it’s still going to take some time to pry enterprise users of Internet Explorer 11 away, Microsoft is hoping that the new Internet Explorer legacy mode in the Chromium-based Microsoft Edge browser will help. It will continue to let businesses access old sites that were specifically built for Internet Explorer, until Microsoft fully drops support for Internet Explorer 11 within Windows 10. Microsoft’s move to stop supporting Internet Explorer 11 with its main web properties is a good first step, though.

It seems like "dropping support" means their Office 365 products will no longer support it. This is definitely good news, don't get me wrong! But it is different than the browser itself reaching end-of-life.

[jhsware]

@mindplay-dk @chowey I agree that IE has an impressive will to survive. But given the negative impact of supporting IE on the other 98%+ of users I don't think the benefit is even close to making it worth it. Even if that means loosing 75% of potential adoption during the first years. This will start off as a niche tool anyway and we have to make life a simple as possible for the author so he has a long and prosperous life! :)

[tooolbox]

Arrow functions done 🚀

Anybody have a full list of what's left?

[evanw]

There's a lot left to do. Going off of http://es6-features.org/, it's something like this (for the syntax-level things at least):

• Block-scoped variables
• Default parameters
• Rest parameters
• Spread operator
• Template tags
• Computed object properties
• Object methods
• Destructuring
• Classes
• For-of loops
• Generators

This is a very significant undertaking and would likely result in the addition of a lot of bugs because these features have a lot of subtlety to them and interact in complex ways. TypeScript and Babel don't even get these features completely right and they have been around for a long time.

Realistically you would also probably need polyfills for various features such as maps, sets, typed arrays, and maybe promises? But esbuild is only concerned about the syntax transforms, not the polyfills, so it's bring-your-own-polyfill.

[chowey]

Realistically you would also probably need polyfills for various features such as maps, sets, typed arrays, and maybe promises? But esbuild is only concerned about the syntax transforms, not the polyfills, so it's bring-your-own-polyfill.

I fully agree! Polyfills can be handled by importing a library such as core-js. Babel has a preset-env that will detect which features you are using that might need a polyfill, and it will automatically add those core-js imports for you. But that is just a convenience. If esbuild does ES5 lowering and leaves polyfills to me, then I am totally satisfied.

[mindplay-dk]

Just a thought, but would it be feasible to bundle with esbuild, and then transpile the completed build with babel?

I mean, during development, you're probably testing with a modern browser anyhow - so you can skip babel, and then maybe the babel step and legacy browser testing is just something you do before a release.

You'd normally have two npm scripts anyhow, right? One for watching during development - and one to build for production, which would pipe the result through babel.

Any reason that wouldn't be feasible? 🤔

[chowey]

Honestly I work with Go-based servers. esbuild has the potential to completely eliminate Node and NPM from my development workflow. An esbuild-based Go HTTP handler could understand JavaScript source trees and generate bundles more-or-less on-the-fly.

There is also the possibility to do pre-compilation of source files, like HUGO does, using a similar pure-Go-based approach.

As you say, we do right now use Node-based tools because we have to. So it is possible to bundle using esbuild and then transpile the completed build with babel. But babel is slow. Like, really slow in comparison to esbuild. I do realize babel is doing extra ES5 lowering (which is more work than esbuild currently needs to do), but still. Really slow.

So while what you say is correct, and it is a good workaround for right now, I still feel it is a worthwhile goal to lower to ES5 directly from esbuild.

[jakearchibald]

Just a thought, but would it be feasible to bundle with esbuild, and then transpile the completed build with babel?

I think this is a good idea, even if esbuild gets first class support for ES5. This could be a plugin hook that gets the opportunity to transform each output chunk, similar to https://rollupjs.org/guide/en/#renderchunk in Rollup.

[evanw]

Thank you for the suggestion. I'm actually thinking about experimenting with a plugin hook like that for other reasons as well. However, it's worth mentioning that doing something like that is already possible with the write: false API option without any additional plugin hooks.

[jakearchibald]

Ohhh yes it does! https://esbuild.github.io/api/#write for others looking for the docs.

[alex-shamshurin]

Guys, IE11 is still in production, because many corps are still use it and cannot switch easily to something new. So we have to support it ( via separate bundles ). Please do support it.

[nettybun]

@alex-shamshurin There are plenty of tools to help you (babel-preset-env, browserlist) and esbuild doesn't have to be that tool. Carrying the baggage to support IE 11 doesn't help move the web forward.

Also: https://github.com/evanw/esbuild/issues/297#issuecomment-694074467

[olavoasantos]

I really like esbuild and can't wait to adopt it. But the lack of es5 (and IE11) support is currently the biggest blocker to do it. While small, when you have millions of users accessing a website, that small percentage translates into many thousands of users. Keeping an eye on this thread. Hope we could find a workaround or an optional config for this.

[alex-shamshurin]

Corporates users, maybe 90% of users can still use IE11 because of many factors.

[nettybun]

@alex-shamshurin PRs welcomed :)

[tannerkrewson]

Here's how I used the write api to optionally transform the output of esbuild with Babel:

const fs = require('fs');
const { build } = require('esbuild');
const babel = require('@babel/core');

const IS_PROD = ...;

...

build({
    ...
    write: !IS_PROD
}).then(({ outputFiles }) => {
    if (!IS_PROD) {
        console.log('\nThis is a dev build. Babel was skipped.');
        return;
    }
    
    console.log('\nThis is a prod build. Running Babel...');
    
    for (const { path, contents } of outputFiles) {
        const raw = new TextDecoder().decode(contents);
    
        if (path.endsWith('.js')) {
            babel.transform(raw, {}, (err1, res) => {
                if (err1) throw err1;
    
                fs.writeFile(path, res.code, { flag: 'w' }, (err2) => {
                    if (err2) throw err2;
                });
            });
        } else {
            // don't run css through babel
            fs.writeFile(path, raw, { flag: 'w' }, (err2) => {
                if (err2) throw err2;
            });
        }
    }
});

[max-hk]

@tannerkrewson It doesn't work with preset-env.

[mindplay-dk]

@tannerkrewson It doesn't work with preset-env.

To elaborate slightly, this is similar to what I came up with myself - and yes, with preset-env adding require statements for runtimes/polyfills, you just end up with something that needs to be bundled again.

And with the Babel plug-in, you have the reverse problem: it adds code that needs to be lowered again.

At this point, I don't believe Babel can be integrated in any meaningful way - not if you're trying to lower for IE11.

Personally, I plan to simply bundle again for the IE11 build, e.g. with a full webpack (or maybe microbundle or parcel) build-step via CLI. What does it matter, really, if it's integrated with the script or not? From what I can tell, as soon as Babel is involved, it's going to be slow either way. The overhead of another build tool makes it slightly slower, but it'll be robust and predictable.

[wessberg]

Let me add some additional perspective by sharing my use case. I'm hosting a webservice that generates and sends down a bundle of polyfills on-demand. This bundle is generated and syntax transformed, or "lowered", to the level supported by the user agent requesting the bundle. It might also be minified.

This wasn't feasible to do in the past, but with esbuild being as fast as it is, it actually works great now. But since esbuild does not support targeting es5, I have to first generate some code and a SourceMap with esbuild, and then conditionally run something like swc (which is fast, but has several quirks) or babel (which is slow, but stable) if the user agent requires it.

Additionally, esbuild has the banner and footer options, but in combination with a later tool in the pipeline responsible for transpilation to es5, these banner/footer sections may lose their place in the hierarchy, for example if helper functions are generated and inserted into the head of the bundle(s).

This is a scenario in which speed is essential, and where it would make an enormous difference that esbuild could target es5 directly.

[nettybun]

@wessberg Can you share any perspective as to why it is important to deliver ES5 code and why it's worth your time as a developer to support those browsers? Many apps and services are simply choosing to stop supporting IE8/9/etc.

Or maybe it's another reason, like you've profiled your bundle on V8 and have determined the performance different to be worth the transpilation? Curious why you're using ES5 😁

[pavelbinar]

Hi @heyheyhello ,

Let's get on the same page: we all hate IE8/9/etc.

Curious why you're using ES5

I appreciate you asking this because this requires empathy with developers who "have to" deal with ES5.

Here is my case: We are developing Smart TV applications for HTML5 based OTT platforms (Tizen, webOS, Xbox, Vizio,...). We are trying to be compatible with TVs from 2015 up. Some of these older TV models require ES5, so we have to transpile our ES6+ source.

I see on your GitHub profile status: "Drowning in tooling".

Well, that is what most developers requesting ES5 support want to avoid. Unfortunately, not everyone is a tooling wizard, and dropping the unofficial ES5 support to the production codebase is a great danger.

Here is the proposal/idea, how to solve this non-binary problem.

How about creating official documentation (on the website) how to configure esbuild with Babel. In that case, esbuild would not get ES5 support directly, but at the same time, anyone who "needs" ES5 support would get clear and assuring instructions on how to do it.

CC: @evanw - Thank you for great work on this project!

[wessberg]

@wessberg Can you share any perspective as to why it is important to deliver ES5 code and why it's worth your time as a developer to support those browsers? Many apps and services are simply choosing to stop supporting IE8/9/etc.

Yes. I did already explain this in my comment, though, but I'm glad to repeat the details. I'm hosting a webservice that generates a tailored bundle of polyfills on the fly based on just what the requesting user agent needs. This bundle is then transpiled to the ECMA version supported by the requesting user agent. Websites integrate this webservice, and it's up to them which ECMA version they want to support as their baseline. And I might add that this web service gets traffic from a great variety of browsers and devices from across the world that does not support the entirety of ES2015 (well, almost no browsers implemented tail recursion, but we generally don't count that as not supporting that language baseline).

This is not just IE11, mind you. This is Chrome < 49, Firefox < 45, Safari < 10, Edge < 14, etc.

The world is big and diverse, and we should feel privileged if we're in a position that allows us to target only browsers with full ES2015 support. This is extremely rare in large organizations, and even more so in the public sector. What is becoming more commonplace, thankfully, is differential bundling, which enables teams to move forward with the latest language features and APIs while still delivering a functional product to a large, diverse customer base, whether public or private.

[wessberg]

@pavelbinar

Here is the proposal/idea, how to solve this non-binary problem.

How about creating official documentation (on the website) how to configure esbuild with Babel.

While this would be nice and welcome contribution that would also help with the adoption of esbuild, and while I value your attempt to find some middleground, I would not go as far as say that it would solve the problem. In my posts above I go into details about a use case in which very fast bundling and transpilation to a lower ECMA target than ES2015 may be required on demand, as well as the problems that can arise when combining a tool such as esbuild with other tools like swc or babel. I'm already running swc after esbuild conditionally, if the user agent requires it, and there are many quirks and workarounds that has to be done in this process, including broken input source map support, forced addition of require() calls to regenerator-runtime, and many holes in the language support (swc is still very much experimental, especially for more esoteric syntax where it simply fails for something like new.target or Unicode Code Point Escape.

[mindplay-dk]

How about creating official documentation (on the website) how to configure esbuild with Babel.

That would be great - if it's possible, and I'm not convinced that it is, in any meaningful capacity.

I spent considerably time trying to get a working setup, and my conclusion was that there's no right way to integrate Babel - as plugin, or as a tool to post-process the output, neither approach worked for me. The problem is Babel may require run-times or polyfills - and it's not a bundler, so you end up with something that needs to be bundled again. You could do it, of course - but at that point, you're running ESBuild -> Babel -> ESBuild again to bundle the polyfills, which just seems bonkers.

For the time being, I've settled for manually importing any polyfills as dependencies in my code, so Babel is handling the down-level compilation only. I will most likely end up using microbundle, rollup or webpack with Babel, as an optional second step for the IE11-compatible build - so that basically these are completely separate build-steps. For the second step, I'm not getting any benefit from involving ESBuild, and Babel has closer integration with these other JS native bundlers, so it can actually add run-times, bundle and down-level all in one step.

I would love to see a working setup with just Babel and ESBuild, but I can't fathom how this would be possible. 🤔

[tooolbox]

Tagged template literals are done! So now esbuild can lower e.g. htm to es5.

These are what's left based on Evan's earlier rough list (click the one you're most interested in!)

If I recall, lowering let and const are what @danickinator needed. (Or the ability to target es5 without blowing up on a let or const.)

[Khachatour]

Hello folks, first I want to thank all the maintainers and especially @evanw for this wonderful tool.

To elaborate and also write my own use case. so our use case is a package that bundles with esbuild and we did not have any transpilation stuff. But recently started to get tickets for supporting more legacy browsers, which in fact we can (we don't use anything which swc or babel can't transpile). But personally, I don't want to get rid of using esbuild, the API is simple, it is fast.

Last two weeks I've tried multiple things, esbuild -> swc -> esbuild, having separate bundle with es5 and separate polyfills.

It would be very nice for maybe all of us who tried to do some stuff with lowering down to es5, combine the knowledge, and maybe document this within esbuild or somewhere where the examples are. Like explaining what was the use case and so on and so forth. Personally, for me the open problem is still with the preset-env either with swc which adds import statement in the es5 transpiled output, which is this issue.

I know that esbuild is not aiming to solve this, but people love to use esbuild and want to stick with it. It would be very nice to somehow try to document it. I would like to try and contribute with the examples, but maybe we can also open a discussion thread to gather insights? What you can suggest folks?

Yet again thank you all!

[remko]

@Khachatour I work around the regenerator-runtime issue in SWC by inlining the regenerator-runtime using a regexp.

My flow goes something like this:

esbuild({...., metafile: true}).then(convertToES5)

where the code for convertToES5 is

import swc from "@swc/core";
import { promisify } from "util";
import fs from "fs";
import esbuild from "esbuild";

const writeFile = promisify(fs.writeFile);

// Could also use swc to minify this
const regeneratorRuntime = esbuild.transformSync(
  fs.readFileSync("node_modules/regenerator-runtime/runtime.js").toString(),
  { minify: true, target: "es5" }
).code;

export async function convertToES5(result) {
  const outputs = Object.entries(result.metafile.outputs)
    .map(([out]) => out)
    .filter((out) => out.endsWith(".js"));
  await Promise.all(
    outputs.map(async (src) => {
      const output = await swc.transformFile(src, {
        jsc: { target: "es5" },
        sourceMaps: true,
        // Ran into a bug using SWC's minifier on ESBuild's output. Instead of minfying here,
        // do another ESBuild pass later only for minification
        // minify: true,
        module: { type: "commonjs"},
      });
      output.code =
        regeneratorRuntime +
        output.code.replace(
          /require\("regenerator-runtime"\)/,
          "regeneratorRuntime"
        );

      // Minify again using esbuild, because we can't trust SWC's minifier
      output.code = (await esbuild.transform(output.code, { minify: true, target: "es5" })).code;

      await Promise.all([
        writeFile(src, output.code),
        ...(output.map != null ? [writeFile(src + ".map", output.map)] : []),
      ]);
    })
  );
}

Update: Ran into a bug in the minified SWC code. Now running the resulting SWC file through esbuild again. Unfortunately, this messes up source maps, since ESBuild does not support nested source maps. A proper flow would probably first extract all the resulting sources, and then run ESBuild to bundle everything again.

Another problem with this flow is that SWC sometimes introduces code that resolves ES7 helper methods before you have the chance to load polyfills. The only solution I found so far was making sure that all necessary polyfills are loaded in a separate file, loaded before the main bundle (e.g. by manual vendoring).

[spenat28]

Everybody talks about IE11. I would like to tell you - we need es5 support too - because i work for IP TV platform - and there are many devices with old engines - which we support, but till esbuild doesn't have support for es5 we have to stay with babel. Which is painfully slow.

[mindplay-dk]

@remko sincere question: I haven't really looked at SWC, but had the impression it's aiming for much the same feature set as esbuild - if you're using SWC anyhow, can you clarify, what is it you want from esbuild in the first place? (why not just run your entire build with SWC? is there something esbuild can do that SWC can't?)

[timo-klarshift]

Providing Support for ES5 would open huge possibilities in the go ecosystem IMO. For example people want to run JS in goja which only supports ES5 (with some additions). Supporting ES5 in esbuild would mean people could provide Typescript to a go runtime and the typescript code would be transpiled (on the fly + cached) and then executed in goja runtime. The advantage is that i can remove my bloated nodejs based babel pipeline and all the tooling can ship with a single small go binary instead.

[remko]

@remko what is it you want from esbuild in the first place

(I don't want to hijack this thread with opinion, so sorry if I do)

@mindplay-dk

This is partly historical, but may still be the case:

• The SWC bundler resulted in incorrect code, which scared me off.
• The documentation seemed also quite lacking when I looked at it, especially compared to ESBuild (which has excellent documentation)
• Even though not all features are implemented yet, the envisioned feature set of ESBuild is crystal clear, and matches perfectly what I want (no more, no less). This wasn't as clear for SWC when I looked at it.
• The ESBuild plugin system was clearly documented, easy to understand, and did exactly what I wanted. This allowed me to throw away nearly all third-party plugins (that typically are overly general, buggy, and pull in tons of dependencies), and replace them with a few lines of code of my own.
• The way ESBuild documents changes in the ChangeLog is impressive. I cannot stress enough how much I appreciate such detailed changelogs. Apart from whatever framework you are using for your code, the compiler/bundler is probably the most important part in your toolchain, and understanding what changes over releases is crucial. SWC also keeps a changelog (unfortunately separate from the GitHub releases page, but that's minor), on par with most other good tools, but it doesn't come close to what ESBuild does.

I'm sure SWC is a good project, and will most likely improve over time, but for now, ESBuild inspires more confidence than SWC (and many other projects)

[aripalo]

I did not spot this mentioned before here, so I'll add that AWS CloudFront Functions also target only ES5: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/functions-javascript-runtime-features.html

And as a result one can not utilize ESBuild with AWS CDK for CloudFront Functions in similar manner as normal Lambda functions can be built with ESBuild directly with CDK.

[ScottAwesome]

@evanw I am wondering where one might want to start in adding support for ES5? I'd love to submit code, but I'm not sure where to start exactly with how to down level code properly.

[fr-an-k]

+1

[tooolbox]

@evanw as it's been almost a year since you added lowering of tagged template literals, do you have any thoughts on the remaining points needed for lowering to ES5?

(I don't mean to imply you've been resting on your laurels--you've maintained a pretty blistering release cadence on esbuild in terms of correctness points, the latest TS/JS syntax, and QoL improvements, but I'm curious what plans if any you have for the ES5 area.)

Thanks!