Fix exports for projects consuming this package as an ES module

[liamness]

What does this change?

Adjusts exports in package.json. The module property specified here does not seem to be part of the official Node.js spec. I've noticed that when using vitest, this has led to custom elements not being correctly set up and tests failing—possibly because it tries to import the CommonJS paths provided as if they were ESM. It is possible that in the future, if our projects use a different bundling system, this could cause similar errors in the actual apps at runtime.

The main property is left as is, in case this package is consumed by tooling that doesn't use the exports property.

See "conditional exports" in https://nodejs.org/docs/latest/api/packages.html for more info.

How to test

I have tested this locally by manually editing node_modules/@guardian/prosemirror-elements/package.json with matching changes in a downstream project (Composer). We could test further by doing a "prerelease" but I think this is low risk enough that we could merge, and then revert the changes if problems are found.

How can we measure success?

ES module compatibility!

Have we considered potential risks?

There's an unlikely, but non-zero possibility that this will interact strangely with bundlers used in downstream projects.

[jonathonherbert]

Oh this is interesting, looks like module was a proposal that didn't end up being adopted. Glad there's a standard now 😅 thanks for the PR!

[liamness]

Unfortunately this still can't be consumed as an ES Module, because the import paths don't use the full filename (i.e. they don't end with .js). I must have removed "type": "module" at some point in the debugging process and then forgotten about it. I'll come back with more changes, but in the meantime, this version at least shouldn't break anything for projects consuming this package as CommonJS.