When installing @wordpress/components in a 3rd party repo, some types are broken

[noahtallen]

Description

I recently experimented with updating @wordpress/components to the latest version (23.9.0), and found a few errors when trying to use it with Typescript:

node_modules/@wordpress/components/build-types/text/types.d.ts(46,32): error TS7016: Could not find a declaration file for module 'highlight-words-core'. '/Users/noahallen/source/wp-calypso/node_modules/highlight-words-core/dist/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/highlight-words-core` if it exists or add a new declaration (.d.ts) file containing `declare module 'highlight-words-core';`
node_modules/@wordpress/components/build-types/custom-gradient-picker/types.d.ts(5,33): error TS7016: Could not find a declaration file for module 'gradient-parser'. '/Users/noahallen/source/wp-calypso/node_modules/gradient-parser/build/node.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/gradient-parser` if it exists or add a new declaration (.d.ts) file containing `declare module 'gradient-parser';`
packages/components/dist/types/submenu-popover/index.d.ts(3,39): error TS2503: Cannot find namespace 'Popover'.

I think this could be related to us disabling the lib check in tsc for components:

gutenberg/packages/components/tsconfig.json

Line 17 in 85e2d4e

"skipLibCheck": true,

Step-by-step reproduction instructions

Install the components package in a 3rd party package repo.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[ciampo]

Re. @types/highlight-words-core and @types/gradient-parser, it was my impression that dev dependencies in Gutenberg are declared in the top-level package.json, and not in the individual components. Could you confirm that?

packages/components/dist/types/submenu-popover/index.d.ts(3,39): error TS2503: Cannot find namespace 'Popover'.

This seems to be due to how DT types used to expose a Popover namespace, with the Props property:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/wordpress__components/popover/index.d.ts#L4-L5

We simply don't do that in our first-party types. I guess that could be easily fixed by doing something like

import type { Popover } from '@wordpress/components`;

type PopoverProps = React.ComponentProps< typeof Popover >;

[noahtallen]

Could you confirm that?

Yeah, I think this is true. I also think all @types packages are considered dev dependencies in Gutenberg, which might not always be true -- in this case, if the types aren't getting added to the published package, and it hopes to resolve them via node_modules in "production" (e.g. when it's consumed by other apps), they wouldn't be found

[noahtallen]

Yeah, I think we'll need to refine how we approach this in Gutenberg. (Here's a good description of the issue: https://stackoverflow.com/a/46011417). If our published types include "import x from y", then y needs to be resolvable from node_modules. This works fine in our internal repo, since everything is available in node_modules, but does not work anywhere else.

This also makes it tricky to add a CI rule, because it wouldn't get caught when running tsc in the internal repo unless we remove the node_modules that aren't directly associated with the package at hand -- which would probably cause other issues with actual dev tools.

Ideally, the linter rules about defining dependencies in package.json would catch this, but since the main dependency is defined already, that lint rule can't help us.

[noahtallen]

I think skipLibCheck is a red herring here; it wouldn't catch this particular issue

[noahtallen]

Another side of this is that certain dependencies, like @types/react wouldn't normally cause an issue in this exact situation because the consumer has likely installed them already. As a result, there could be even more of these issues that I didn't find, just because the repo I was testing in already has a lot of type dependencies.

It would probably be worth adding a script to try to report issues here; otherwise we might end up continuously having to fix these. (Though at the same time, we might not be adding @types dependencies frequently enough to justify that.)

[mirka]

Adding a minimal CodeSandbox repro here for reference. npm run build compiles fine, but npx tsc --build will fail.