IE11 browser support

[diondiondion]

I just realised that color2k doesn't work in IE11 out of the box. 😭

It throws a syntax error when encountering the first line of this bit of code:

color2k/src/ColorError.ts

Lines 1 to 5 in f8f29d6

	class ColorError extends Error {
	constructor(color: string) {
	super(`Failed to parse color: "${color}"`);
	}
	}

It would've been great if that was mentioned somewhere on the website or in the docs. I'm also wondering if this is the only incompatible part of the code, and if so, would you be happy to let Babel compile it for IE11? Not sure if that would cause a substantial increase in bundle size.

[ricokahler]

Thanks for brining this to my attention!

I was un-aware that this didn't work for IE. Color2K ships with an ESM bundle and a UMD bundle and my current understanding it that your bundler is supposed to handle transpiling the ESM bundle down to IE 11 compatible JS.

Can you provide more info on what bundler you're using and your babel settings? If you're using webpack, can you paste your webpack config?

[diondiondion]

Hi, thanks for the quick response!

The repo that directly depends on color2k is 5app/base5-ui, which doesn't use a bundler. The link will take you right to the .babelrc file.

In the (private) repository consuming base5-ui, we're working around the issue now by explicitly compiling color2k using the approach shown below, but it's a bit hacky since that repository doesn't directly depend on color2k.

module: {
	rules: [
		{
			test: /.jsx?$/,
			exclude: [
				/node_modules\/(?!color2k)/,
			],
			use: {
				loader: 'babel-loader'
			}
		}
	]
},

I'm not that well-versed in bundling & build-tooling, so I wasn't able to use this approach directly in base5-ui, which uses Babel directly without a bundler.

my current understanding it that your bundler is supposed to handle transpiling the ESM bundle down to IE 11 compatible JS.

Babel is usually, or at least by default, set up to ignore anything inside of node_modules, so this wouldn't happen by default. But it seems to be a contentious topic and I can understand not being happy about compiling packages down to the lowest common target. 😅

However in this case it seems like the offending part of the code is small enough to be compiled by default without penalty.

Feel free to let me know if you need any other info from me to assist with this.

[ricokahler]

/node_modules\/(?!color2k)/,

Ooof that one-off hurts me lol.

---

Babel is usually, or at least by default, set up to ignore anything inside of node_modules, so this wouldn't happen by default. But it seems to be a contentious topic and I can understand not being happy about compiling packages down to the lowest common target. 😅

I do compile it down to the lowest common target for the UMD build (beeeg ugly bundle, compatible with your toaster and beyond) but for the ESM build I try to keep it relatively simple and modern.

As a quick test, I booted up create-react-app and imported color2k to see how they handle it and from what what I'm seeing, they do compile this down. I don't know if that's the result of the bundler piping it through babel differently or the minifier removing the class though.

---

However in this case it seems like the offending part of the code is small enough to be compiled by default without penalty.

I tried this out in #247 and i'm not too sure if I like the result for other reasons besides bundle size.

I'll have some time later this week to investigate but if you can find some articles/sources on best practices for ESM builds + how other pre-configured bundlers (e.g. create-react-app, next.js) work that would greatly help!

[ricokahler]

@diondiondion any update on this?

[diondiondion]

@ricokahler Sorry for not giving an update on this, I simply don't know enough about builds & bundlers to give you any qualified input on this. I asked some coworkers for input on this weeks ago, but they seemed to be happy to live with our color2k-specific workaround, so it seems like there really is not much you're doing wrong on your side.

[ricokahler]

@diondiondion my apologies for closing. I actually stumbled upon this somewhat new video by google chrome developers about "transitioning to modern javascript". They mention that there's a new type of entry point field call exports that your bundler may be able to utilize better than the modules entry point I use today.

I may switch to entirely if it makes sense. Here's the video with a timestamp. Very informational.

I think I'll open an issue to try it out. Maybe this weekend.