Bug: React not defined in TypeScript when importing from npm

[nestarz]

React version: all

Steps To Reproduce

1. Import React from "npm:react" inside Deno
2. Observe that React is not defined in TypeScript

Code example:

import * as React from "npm:react";
// here React is not defined in typescript, we need to add @types/react
/* @deno-types="@types/react" */
import * as React from "npm:react";

The current behavior

React is not defined in TypeScript when importing it from "npm:react".

The expected behavior

React (and react-dom) should ship with types, at least in a .d.mts form, so that users don't have to bother adding types manually. As TypeScript is now widely used, React should provide first-class TypeScript support.

Related issue: denoland/deno#18203 but the solution we have doesn't address the issue directly. Maybe React should ship types and not the @DefinitelyTyped org.

[eps1lon]

It's definitely something to explore long term but not trivial to do. Does Deno not support any JS library that ships types in @types/*?

[nestarz]

Types must be manually added, from the documentation:

Providing types when importing: If you are consuming a JavaScript module and you have either created types (a .d.ts file) or have otherwise obtained the types you want to use, you can instruct Deno to use that file when type checking instead of the JavaScript file using the @deno-types compiler hint. @deno-types needs to be a single line double slash comment, where when used impacts the next import or re-export statement.

https://docs.deno.com/runtime/manual/advanced/typescript/types

And the solution to support any JS library that ships types in @types/* is disscused here: denoland/deno#18203 (comment)

But overall, it isn't specific to Deno, as it's a React choice to have (or not) a first-call TypeScript experience and deliver types in it's own scope and specified directly from it's own package.json.

Can I ask why it isn't trivial as the effort to make the types is already well known ? isn't it just a copy paste from the @DefinitelyTyped codebase into the facebook/react codebase ?

[eps1lon]

isn't it just a copy paste from the https://github.com/DefinitelyTyped codebase into the facebook/react codebase ?

It needs release coordination which isn't trivial considering the amount of users we have. Moving types from @types/ to the actual library is a breaking change.

And then we have to figure out integration testing.

[nestarz]

Ok thanks for the follow up. Do you think React 19 can be a good target, as it's a new major version and that would allow such breaking changes ? But you know more about the repercussion that it would trigger ! and I don't know how I can bring the @types team to follow up this discussion so that integration become painless.

[markerikson]

Another way to put it is:

There's been significant iteration on the React types over the last couple years, but zero official React releases during that time.

With the current structure, at least those types updates can be shipped separately.

(Perhaps if the types were included, the React team's release approach would change, but for now at least the separation has a benefit.)

[nestarz]

I understand the logic, but what if types could be updated in a patch semantic version (major.minor.patch) ? so types could be in a faster iteration than other updates. I don't get the benefit, we are talking about future release, ideally starting a major version like 19, what downside changing the release approach would have, if it's documented.

And again, I'm confused on why TypeScript support has to be done separately, by another team, isn't TypeScript used by a majority of library authors ? compagnies and users ? Isn't it a feature that would benefit the ecosystem if it's managed by the React team ? I know React use Flow and I think that's the main reason of the current state, but maybe the @DefinitelyTyped react types contributors would like to make PR to the react codebase with the types they are writing.
But again, I'm not one of those contributors and I'm not a react team member, it's just that I feel that it could be improved.

[eps1lon]

I maintain the React types and I'm on the React team. The TS types just weren't part of React historically so there's a lot of catching up to do.

[ali09raza]

Deno doesn't natively include type definitions for external libraries like React.
TypeScript requires type information for imported modules to ensure type safety.
Solution:

Install Type Definitions:

Use the deno add command to install the @types/react package:

Bash command:

deno add -D https://deno.land/x/types/react@v18.0.22/react.d.ts

Replace v18.0.22 with the specific React version you're using for compatibility.

Import Type Definitions:

In your TypeScript file, add a @deno-types comment at the top to specify the type definition file:

TypeScript
/* @deno-types="https://deno.land/x/types/react@v18.0.22/react.d.ts" */

import * as React from "npm:react";

Explanation:

Installing @types/react provides the necessary type information for React.
The @deno-types comment instructs Deno's TypeScript compiler to use these types for the react import.
Additional Considerations:

If you prefer a different version of @types/react, adjust the version number in the deno add command and @deno-types comment accordingly.
Consider using a bundler like Vite that handles dependencies and type definitions automatically. Explore Deno's built-in bundling capabilities as well.
Example Code (After Fix):

TypeScript
/* @deno-types="https://deno.land/x/types/react@v18.0.22/react.d.ts" */

import * as React from "npm:react";

function MyComponent() {
return

Hello, world!

;
}

React.render(MyComponent, document.getElementById('root'));

With these steps, your TypeScript code should now recognize React and provide type safety for your React components in Deno.