How to target IE11 using microbundle?

[ydennisy]

I am using microbundle and typescript. I have followed the advice and set target and module to esnext, and have tried to add a browserslist key in the package.json, but the build from microbundle does not differ with various settings.

My command:

	npx --no-install microbundle \
	  -i src/index.ts \
	  -o dist/sdk/edgekit.min.js \
	  -f umd \
	  --pkg-main false \
	  --compress true \
	  --external none \
	  --sourcemap \

[developit]

@ydennisy what value were you providing for the "browserslist" key? The default output for the umd target should already be IE11-compatible, but it doesn't auto-polyfill things.

[ydennisy]

@developit thanks for your reply.

It seems my understanding is a little off - my thought was that this would convert uses of things such as fetch to something compatible for IE11, so what would be the best practice for making the bundle actually run on IE11, would we manually have to maintain what we used and the polyfills from something like core-js?

Also how would we know what has been transpiled VS needs to be polyfilled?

[developit]

Microbundle only polyfills JS language features. It doesn't do DOM polyfilling because it's too unreliable to do correctly.

In general if you're using a DOM API that isn't supported in the browsers you're targeting, it's best to import that polyfill yourself. General-purpose automatic polyfilling is one of those things that sounds good in theory, but in practise it does more harm than good.

For fetch, if you're just using the basic fetch() function (not the Headers API), you might find Unfetch fits the bill - it's 500b and supports IE9+.

For Promise I always recommend the promise-polyfill package - it's 1kb and does reasonable deferral scheduling in IE.

core-js is generally not the best place to look for DOM polyfills, since it's not particularly modular. Importing Fetch from core-js will end up pulling in a whole bunch of stuff like Set and Map - which are already supported in IE11.

As a last point, Microbundle is mainly aimed at bundling JS libraries. In general, it's best to avoid relying on things like fetch() in a library if you want to support IE11. Failing that, tiny "poorlyfills" like Unfetch are the next best thing. You get to rely on the API you want, and you don't have to bundle a huge chunk of polyfills into your library.

[ydennisy]

@developit thanks very much for this - huge help!

One final question: is there any automated way / best practice to test / analyse code for suitability for browsers?

From my current understanding browserstack is an option - or just running tests in all the browsers.

I was wondering if there is a static analysis tool which will flag DOM APIs which are not present in all targeted browsers?

Thanks again.
Dennis

[Antonio-Laguna]

@developit I was checking this as I was releasing a library using microbundle and I get untranspiled code which would deem this not usable on IE11 and I think it also is different with what the README.md says.

I'm not getting const nor class transpiled which is creating issues since by default node_modules aren't transpiled. I'm just using recommended settings here: https://github.com/firstandthird/domodule/blob/main/package.json

Yet I get

[rschristian]

@Antonio-Laguna That's the ESM output you're looking at, which is, at a minimum (not sure on specifics), ES6. That is transpiled as you will see differences between it and the modern output (if you're using newer features).

If you want IE you're going to need to use the CJS or UMD outputs (domodule.js and domodule.umd.js)

[Antonio-Laguna]

@rschristian

ESM should be transpiled without any imports working since Babel doesn't transpile node_modules (by default), hence what you get is untranspiled code all the way which is undesired.

Also, this is from the README.

See how let gets converted into var? Also, UMD has the same behavior in which class and const stay.

[rschristian]

@Antonio-Laguna UMD having class and const is definitely an issue but, as far as I'm aware, ESM containing let and const is perfectly fine. Edit: I have been made aware of more things.

I'm at work now, so can't check, but this might be that babel config you have in the repo.

[Antonio-Laguna]

I don't think it's fine given the screenshot and given Babel thing. How do you use modules without transpiling node_modules?

Also... 🤦 that babel thing was messing it out and I completely disregarded it. Thanks a lot! Doing that gets rid of const everywhere.

[rschristian]

I don't think it's fine given the screenshot and given Babel thing. How do you use modules without transpiling node_modules?

Well I do believe it should be fine, but not an expert here. Generally I don't transpile node_modules. Libraries should provide the right targets or that's the job for an application tool to handle. Using dependencies with Microbundle should push the node_modules issue downstream to the the application level where they can decide how they want to handle that.

Learned a few things, ignore me.

Also... 🤦 that babel thing was messing it out and I completely disregarded it. Thanks a lot! Doing that gets rid of const everywhere.

Glad that worked.

[ydennisy]

@developit sorry to bring this up again, but I have not been able to find instructions on how one might use microbundle to ponyfill promises when using async / await.

The project is a lib which will be used in 3rd party web pages, so we must avoid overwriting any globals. Right now we are using microbundle without any extra configuration.