chore: maintain package

[lihbr]

Types of changes

• Chore (a non-breaking change which is related to package maintenance)
• Bug fix (a non-breaking change which fixes an issue)
• New feature (a non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

See commit history~

Checklist:

• My change requires an update to the official documentation.
• All TSDoc comments are up-to-date and new ones have been added where necessary.
• All new and existing tests are passing.

🐢

[angeloashmore]

LGTM! I just left one small style comment for size-limit.cjs.

[lihbr]

LGTM! Thanks for updating it

[lihbr]

Does this install well? 🤔 Wondering if NPM could not be confused by the recursive dependency. I guess we'll discover it soon enough.

[angeloashmore]

Eek, it doesn't. I was worried about that before as well (Slack thread), and unfortunately it seems there is an issue.

Here's the error I see after installing @prismicio/richtext into nextjs-starter-prismic-multi-page:

[next] - error Failed to load next.config.js, see more info here https://nextjs.org/docs/messages/next-config-error
[next] (node:24766) Warning: Accessing non-existent property 'RichTextNodeType' of module exports inside circular dependency
[next] (Use `node --trace-warnings ...` to show where the warning was created)
[next] /Users/angeloashmore/projects/prismic/nextjs-starter-prismic-multi-page/node_modules/@prismicio/richtext/dist/types.cjs:5
[next]   [client.RichTextNodeType.listItem]: "listItem",
[next]                            ^
[next]
[next] TypeError: Cannot read properties of undefined (reading 'listItem')
[next]     at Module.<anonymous> (/Users/angeloashmore/projects/prismic/nextjs-starter-prismic-multi-page/node_modules/@prismicio/richtext/dist/types.cjs:5:28)
[next]     at Module._compile (node:internal/modules/cjs/loader:1254:14)
[next]     at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
[next]     at Module.load (node:internal/modules/cjs/loader:1117:32)
[next]     at Module._load (node:internal/modules/cjs/loader:958:12)
[next]     at Module.require (node:internal/modules/cjs/loader:1141:19)
[next]     at require (node:internal/modules/cjs/helpers:110:18)
[next]     at Module.<anonymous> (/Users/angeloashmore/projects/prismic/nextjs-starter-prismic-multi-page/node_modules/@prismicio/richtext/dist/wrapMapSerializer.cjs:3:15)
[next]     at Module._compile (node:internal/modules/cjs/loader:1254:14)
[next]     at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
[next]
[next] Node.js v18.16.0
[next] npm run next:dev exited with code 1

We could either:

1. Move rich text-specific types into @prismicio/richtext, removing the dependency on @prismicio/client.
2. Merge @prismicio/richtext into @prismicio/client, resulting in a breaking change, but simplifying the ecosystem.

#1 seems like the better and simpler solution, but what do you think?

[lihbr]

I'm fine with 1.

I considered also 3. which would have been about inlining @prismicio/client types in @prismicio/richtext (at build time), but this might cause more issues in the long run as we improve/fix types

[angeloashmore]

I opened a PR implementing idea 2 (merge @prismicio/richtext into @prismicio/client) after attempting idea 1 (move rich text-specific types from @prismicio/client into @prismicio/richtext).

Pull request: prismicio/prismic-client#318

Idea 1 didn't work well since many rich text node types depend on field types which only live in @prismicio/client.

While we could copy the types over or inline @prismicio/client, we could eventually run into type incompatibilities and implementations change. Merging @prismicio/richtext into @prismicio/client allows us to change implementations without mismatching types.