Align package.json main fields to point to CommonJS bundles

[pcvera]

Hello!

This PR targets backwards-compatibility for these packages. We found that, in my work's legacy build system, Jest falls down on the openapi-fetch package because of the reported syntax error:

/[path]/node_modules/openapi-fetch/dist/index.js:8
export function randomID() {
^^^^^

SyntaxError: Unexpected token 'export'

This is a symptom of Jest expecting to find CommonJS syntax and unexpectedly finding ES Module sytanx.

Jest can handle CommonJS when specified in main or ES Module syntax when specified in module, but it isn't resilient to receiving ES Module syntax from main where its expecting CommonJS.

The goal for this change is to improve backwards compatibility with legacy resolution. Most more recent systems will prefer the paths in exports, which all of these packages already have specified.

There are other options for improving the legacy Jest case, but this is the lowest-churn way, without changing build systems or holistically modifying resolution for the package.

Caveat

I'm not certain this is an official standard - that main corresponds to CJS. It's hard to find concrete recommendations saying this directly, the closest thing I can find is that the Node JS documentation says about the main field:

It also defines the script that is used when the package directory is loaded via require()

where require is a CommonJS syntax.
reference

Changes

Align the existing main fields in this repository's package.json files on their CommonJS bundles.

How to Review

How can a reviewer review your changes? What should be kept in mind for this review?
Confirm the main fields are aligned with exports.require and make a philosophical call about whether that's consistent with their understanding of the main field in package.json. 😬 For reference, the openapi-metadata package is already aligned, but the swr-openapi package takes another strategy of specifying "type": "module" (I think).

Checklist

• [n/a] Unit tests updated
• [n/a] docs/ updated (if necessary)
• [n/a] pnpm run update:examples run (only applicable for openapi-typescript)

[netlify]

👷 Deploy request for openapi-ts accepted.

Name	Link
🔨 Latest commit	980df59
🔍 Latest deploy log	https://app.netlify.com/projects/openapi-ts/deploys/681516c3b94e8400089104f1

[changeset-bot]

⚠️ No Changeset found

Latest commit: 980df59

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pcvera]

I'm not sure what I can do about this failure - I haven't modified the build command, and the failing test requires a relative path, which isn't going to consult package.json.

Could it be a flake?

[drwpow]

Thanks for raising! While I don’t mind improving support for older systems, this is too big of a change (technically this is a breaking change, and would require major version bumps).

To my knowledge, Jest should respect exports just fine. It’s usually Node.js that is the problem. What version of Jest / Node are you seeing a problem on?

[drwpow]

Just marking “request changes” for now since this is an undiscussed change that could have big consequences. That doesn’t mean I’m opposed to this landing, I just wanted to make clear to the other maintainers some alignment is still needed here.

[pcvera]

It took some investigation, but it looks like our tooling calls into 27.5.1, which is actually more recent than I would have expected.

[drwpow]

So good news—I am going to do some work to upgrade our libraries to all use unbuild, a bundler I’ve been impressed with and it has really good ESM <> CJS support. I’m going to close this because the next openapi-fetch release will ship with that, which hopefully should fix your issue! But please open another issue if it doesn’t fix the problem (look out for a minor release for openapi-fetch—we use minor releases pre-1.0 to indicate some breaking change even if it’s a theoretical breaking change)