fix(types): package.json exports field; export utility types

[ctjlewis]

TS throws and wants us to set the types in the exports field.

• https://nodejs.org/api/packages.html#exports-sugar
• Types that are found, but not exported in package.json, should still be usable microsoft/TypeScript#52363
• Types not inferred in package.json #95

That issue was closed but this is still an issue on latest version.

Btw, this mostly happens because the exports field is defined and so it's being used for module resolution - if it were empty, this error would actually go away and it would fall back to using package.json > types. But since we're using the (correct, modern) exports field, we have to set exports > . > types to chess.d.ts.

[ctjlewis]

Draft for now, I get an error about not configuring a default export...

[ctjlewis]

I see, it's that plus the legacy export = Chess in chess.d.ts.

I exported all of the types, so that anyone can use the util types with import { type King, type ChessEvent, ... } from "chess", and we declare the same module shape with export declare const Chess: { ... }; export default Chess.

This is working for me locally.

We can apparently do it even more simply with:

"import": "./src/main.js",
"require": "./cjs/main.cjs",
"types": "./@types/chess/chess.d.ts"

But I would leave it the way it's submitted here in case you ever want to add module paths like chess/something.

Really great job with the library btw, let me know if you need any changes to this PR and I'll get them in quickly.

[ctjlewis]

Damn hahahah this has been a real game of whack-a-mole, I just saw #96. It came back only because the types field wasn't re-added, if that had been in there it would have worked: 32983bd. The idea of exports is it's like a whitelist and if it's being used, module resolution is supposed to treat it as a source of truth, so that's why TS started saying "you have types declared, but that file isn't supposed to be exported."

I imagine this worked when it was merged but TS has updated to respect exports more.

This PR basically just re-adds the types to exports, and then in the actual chess.d.ts exports all the types so that we can import them - they're currently used for type-checking but downstream you'd have to infer everything and use typeof, couldn't import { King }.

I guess explicitly defining the . entrypoint is kind of redundant, we could flip that back but it is more explicit and easier to extend.

[coveralls]

coverage: 95.906%. remained the same
when pulling 0ab4f95 on ctjlewis:patch-1
into 8ec37b3 on brozeph:main.

[brozeph]

@ctjlewis Thank you! Dope PR... I merged, made a tiny adjustment to the package.json and updated dependencies. It's now released as v1.5.1 in npm. I also added you to the contributors list. Cheers!

[brozeph]

Also, not sure if it's useful or not for your use case, but I recently put out a Go port of the algebraic parsing component of this library in Go (https://github.com/brozeph/chess - go get -u github.com/brozeph/chess).