[colors] fix: output legacy ESM

[shim-flounce]

Checklist

• Includes tests
• Update documentation

Changes proposed in this pull request:

This PR adds the module field to package.json for legacy ESM (instead of exports which would potentially be a breaking change). To ensure backwards compatibility (e.g. someone importing from the lib directory), the CommonJS build will still go in the lib folder, although in the rest of the repo it goes in lib/cjs. Similarly, the ESM build will go into esm instead of lib/esm (because lib is already “taken”).

Reviewers should focus on:

Screenshot

[adidahiya]

@shim-flounce when did this break / regression occur?

[shim-flounce]

@shim-flounce when did this break / regression occur?

Sorry, what do you mean? I think this package has never had an ESM output despite the fact that the script in package.json says compile:esm. The fact that it’s CommonJS can cause some bundling issues in Vite/Rollup when you use chunking (code splitting) - these tools are ESM-first and don’t handle CJS as well as they do ESM.

[adidahiya]

If it was always broken, then let's just fix it for Blueprint v5 so we can ignore backcompat. Can you send a PR to the next branch and make the output folders match the other packages (lib/esm, lib/cjs, etc.)?

[shim-flounce]

If it was always broken, then let's just fix it for Blueprint v5 so we can ignore backcompat. Can you send a PR to the next branch and make the output folders match the other packages (lib/esm, lib/cjs, etc.)?

I can do, but is there any chance this can be fixed in v4 as well?

[adidahiya]

@shim-flounce ok, yeah, we should fix this in v4. I decided to do it with a change in file paths. Submodule paths of @blueprintjs/ packages are not part of the public API, so it's not a semantic breaking change. Closing in favor of #6179

[shim-flounce]

Thank you @adidahiya!