Support named exports in the ESM mode

[prantlf]

Proposal

Allow importing single exported named functions:

import { bold, green } from "picocolors"

Problem

If named exports are used today, the following error will be thrown:

> rollup -c --environment NODE_ENV:production

[!] SyntaxError: Named export 'bold' not found. The requested module 'picocolors' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'picocolors';
const { bold, green } = pkg;

file:///Users/prantlf/Sources/github/d3/rollup.config.js:2
import { bold, green } from 'picocolors';
         ^^^^
    at ModuleJob._instantiate (node:internal/modules/esm/module_job:132:21)

Changes

Expose an ESM module with named exports: picocolors.mjs. Generate its content from picololors.js by build.mjs. Test that the exports can be imported by test/esm.mjs.

Also upgrade development dependencies. Keep the same major versions of chalk and clean-publish not to break the legacy Node.js tests.

Also include tests with Node.js 20 and move versions older than 18 to the legacy group. Upgrade GitHub actions for modern Node.js.

Also fixes #50.
Also fixes #59.

[elturpin]

Would it not be more logical to put the compiling of the types tests during the test script? As it is a way to tests that types are correct.

Also maybe adding --noEmit option to not produce any compiled files of the test, no ?

[alexeyraspopov]

These are very good changes, but we're not yet dropping these much of old LTS Node.js versions.

On the subject, I honestly can hardly understand the reason you'd want to import every single color separately. It just puzzles me how this can be convenient.

With default export I don't need to go back and forth updating import (even if auto import enabled in an editor of choice). This feels like an unnecessary mental overhead.

[FractalHQ]

This feels like an unnecessary mental overhead.

Pressing the tab key imposes negligible mental overhead. I use named imports habitually by default, so it feels wrong when I'm forced to import an entire module even though I'm only using one or two functions from it.

[alexeyraspopov]

I'm forced to import an entire module even though I'm only using one or two functions from it.

This is Node.js, there is no tree-shaking, both import some_default and import { methodA, thingB } do import an entire module regardless of what you end up using.