Add a UMD build to support older environments

[sholladay]

Closes #44

Following the discussions in #44 and #46, we decided to only convert module syntax. This does not transpile the code to ES5, so extremely old environments are still not supported out of the box. Rather, this makes it easy to import ky in non-ESM environments, such as Node.js.

I went with Rollup instead of Babel, because it is simpler to configure and its output is slightly better (easier to read 👀 and no hardcoded AMD ID).

[sindresorhus]

What are your thoughts on using the "module" field in package.json for the ESM source and "main" for the CommonJS version?

Per https://babeljs.io/blog/2018/06/26/on-consuming-and-publishing-es2015+-packages

[sholladay]

What are your thoughts on using the "module" field in package.json ...

I thought about this for a bit and IMO, it is probably unnecessary. Here is the impact as I see it:

• For bundlers: Seemingly no difference. I've been successfully bundling ky in my own apps with Rollup for months, with no special config. From what I read, Webpack and Parcel should also be able to handle the existing ESM index.js file just fine, without using module.
• For browsers: They just download whatever file you specify and don't consult package.json.
• For CDNs: Probably varies. IIUC, the unpkg CDN does pay attention to main, but not module. So in this case, having main / index.js be ESM is preferable, since using a CDN implies the environment is probably a browser, and all of our supported browsers support ESM.
• For Node: This seems like the one area where main as CJS and module as ESM would benefit. It would allow people to require('ky') instead of require('ky/umd').

So the choice appears to be between giving preferential treatment to ESM users on unpkg or CJS users on Node. The former seems like the obvious choice to me.

[sindresorhus]

Good points. I agree. Let's not do it.

Webpack also seems to have several problems with the module field:

• Bug in Webpack 3 and 4: can't require a module with a ESM entry point webpack/webpack#6584
• module gets prioritised over main webpack/webpack#5756

[sindresorhus]

Should we update https://github.com/sindresorhus/ky#download and https://github.com/sindresorhus/ky#how-do-i-use-this-without-a-bundler-like-webpack to also have a UMD version?

[sholladay]

I added to the "without Webpack" FAQ, but not to the download links. Just thought it would be a bit cluttered otherwise, since the list is of alternative CDNs. I suppose we could reformat it as a table, but I just left it alone for now.

[sindresorhus]

Agreed. Looks good now :)

[FredKSchott]

In case you ever want to revisit this, it's fairly unexpected for require("package-name") to fail on Node.js, unless you specifically don't want to support Node.js.

@sholladay you mention that the choice is between "giving preferential treatment to ESM users on unpkg or CJS users on Node". You could support everyone with:

// Node.js loads umd
"main": "umd.js",
// Bundlers load esm
"module": "index.js",
// Unpkg loads esm
"unpkg": "index.js",

From the unpkg docs:
If you omit the file path (i.e. use a “bare” URL), unpkg will serve the file specified by the "unpkg" field in package.json, or fall back to "main".

Happy to submit a quick PR if there's interest.

[sholladay]

Thanks for the suggestion. I'm not entirely opposed to that, although it would be much better if unpkg just respected module like the bundlers do. And I wonder what other tools this might affect. We definitely want to give preference to ESM without tweaking config for various tools.

Do you know if there are any plans for that?

[FredKSchott]

Agreed, I can't find the tweet right now but I remember Michael Jackson sharing regrets that he'd built this for "main" and not "module"/"umd" but feeling that it would break too many consumers to change it now.

"module" is pretty well supported right now as the "esm"/"web" entrypoint for packages. I've been tracking it's growth over here: https://www.pikapkg.com/about/stats. Pikapkg.com is a catalog of ESM packages, and it uses "module" to detect which packages export web-friendly ESM (since bundlers are the only real consumers of it, it's a safe, feasible guaranteed way to go about it).

I'm not sure about those webpack bugs shared above, but both seem to deal with CJS/ESM interop problems that wouldn't affect this library (in UMD you export your default under the correct default property).