Real-time collaboration: Add typings in core-data for @wordpress__blocks

[chriszarate]

See WordPress/wordpress-develop#10282
See WordPress/wordpress-develop#10283

What?

Add typings in core-data for @wordpress__blocks.

Why?

These hard-coded typings avoid the use of @ts-expect-error, which generates a TypeScript error in build environments where typings for @wordpress/blocks might be incidentally available or inferred. One prominent example is when Gutenberg is built inside wordpress-develop (example build log).

How?

• Add type declarations for @wordpress/blocks inside of packages/core-data.
  • Define only what is used by TypeScript files.
• Including these type declarations in tsconfig.json.

Once @wordpress/blocks defines and provides its own types, this change can be reverted.

Testing Instructions

$ git clone git@github.com:WordPress/wordpress-develop.git
$ cd wordpress-develop
$ npm install
$ cd src/wp-content/plugins
$ git clone git@github.com:WordPress/gutenberg.git
$ cd gutenberg
$ npm install
$ npm run build

Testing Instructions for Keyboard

n/a

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: chriszarate <czarate@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: aaronjorbin <jorbin@git.wordpress.org>
Co-authored-by: SirLouen <sirlouen@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Flaky tests detected in e9231c9.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18599600115
📝 Reported issues:

• [Flaky Test] should refresh the page when stylesheet loading fails #71722 in /test/e2e/specs/interactivity/router-styles.spec.ts

[ramonjd]

Thanks for the PR!

I think this is a pragmatic fix. It addresses the root cause, and is targeted/minimal.

I can confirm that the build passes according to the PR test steps.

Before

After

[aaronjorbin]

Tested and fixes the issue with having GB in a wordpress-develop checkout for me, but I'll defer the final decision on merging to someone who has a sense of if this is the correct direction

[SirLouen]

Working for me also

Just wondering why

gutenberg/packages/core-data/src/utils/crdt.ts

Line 9 in c21a48d

// @ts-expect-error No exported types.

Is passing though

[youknowriad]

The way we incrementally type packages in Gutenberg so far is not by defining .d.ts files, instead we prefer to rename the files to .ts files and add the right config to the .tsconfig files to only type check the TS files which allows us to incrementally type the different packages.

[SirLouen]

we prefer to rename the files to .ts files and add the right config to the .tsconfig files to only type check the TS files

@youknowriad can you show me an example of a package that is already doing this?

I think that the work that has to be done for this to pass in the blocks package is pretty big. There are a ton of files ignoring non-typed elements from blocks. (I've counted 10, including the one in this PR). And I will say that more than half, if not all, blocks files are being imported in one way or another. So the work to be done here is going to take a while.

Meanwhile, this obviously is a hacky way to go through this process, but I wonder if having this in place could hinder the future conversion to TS of the blocks package?

[youknowriad]

The editor package is doing this. Here's the config.

"compilerOptions": {
		"checkJs": false
	},

The blocks package is a fundamental one and a migration to TS would bring a lot of benefits IMO. That said, I agree it's a bit of a challenge but that might be an opportunity to start thinking about it.

[SirLouen]

The editor package is doing this. Here's the config.

"compilerOptions": {
		"checkJs": false
	},

The blocks package is a fundamental one and a migration to TS would bring a lot of benefits IMO. That said, I agree it's a bit of a challenge but that might be an opportunity to start thinking about it.

Oh, I thought you meant that it was possible to migrate one TS at a time. But with this method, it's all or none, right?

[youknowriad]

Oh, I thought you meant that it was possible to migrate one TS at a time. But with this method, it's all or none, right?

No, it's one at a time, only .ts files are type checked, so you start renaming files one at a time.

[SirLouen]

Oh, I thought you meant that it was possible to migrate one TS at a time. But with this method, it's all or none, right?

No, it's one at a time, only .ts files are type checked, so you start renaming files one at a time.

I was just wondering why they did this #48604 then... It's seriously disgusting to review knowing that one file can be incremental at a time, much easier to review, I'm wondering if we could split that PR and make it happen (plus now 5 hunks are failing to apply).

Also, with this in the works, pretty much we can close this one.