@storybook/react (and possibly others) require node types

[robbiespeed]

Similar to #8343 the typings generated for @storybook/react end up including node and polluting the global types.

From the top of the generated @storybook/react/dist/client/preview/index.d.ts:

/// <reference types="webpack-env" />
/// <reference types="node" />
import { ClientStoryApi, Loadable } from '@storybook/addons';
import './globals';

Node types do not need to be included, webpack-env provides the needed type for NodeModule. However looking at the source files nothing in react/client directly imports node, it seems like it's happening in react/server first which then triggers the NodeModule type in the client to reference both webpack-env and node globals since it's not sure which one holds the correct type.

One solution would be to replace NodeModule with __WebpackModuleApi.Module in storybook/app/react/src/client/preview/index.ts, or creating a local Module interface to use.

Another option is splitting up the server and client, whether that's making them build separately (with separate tsconfigs), or moving them to separate packages. Much more work, but would lessen the risk of node types accidentally popping back into the client types.

I haven't checked the built types for @storybook/preact, but judging from the source files it's also likely suffering from this issue. Worth checking all the clients, since node globals interfering with DOM globals is a common and annoying issue for frontend typescript devs.

[shilman]

@gaetanmaisse can you lend a hand here?

[gaetanmaisse]

Sure! I will take a look at that as part of the dependency cleaning work I planned.

[gaetanmaisse]

I would have thought that specifying "types": ["webpack-env"], in tsconfig would have helped tsc to use only webpack-env types and not node ones. But it looks like it doesn't change anything 🤔 I'm still investigating this 🔍 .

-- As per TS doc:

For declaration files generated during compilation, the compiler will automatically add /// for you; A /// in a generated declaration file is added if and only if the resulting file uses any declarations from the referenced package.

So I guess I will need to manually use __WebpackModuleApi.Module to avoid tsc to include @types/node too

[robbiespeed]

@gaetanmaisse using typescript project references would be another option, node types are pulled in now because they are part of the same project as the server which does use the node types and makes "types": ["webpack-env"] behave as "types": ["webpack-env", "node"] across the whole project.

https://www.typescriptlang.org/docs/handbook/project-references.html

Though I'm not familiar enough with the storybook build process to know if it could be tweaked without a huge effort, to allow building using project references.

[100terres]

Has anyone found a way to resolve this issue ? :slightly_smiling_face:

I'm maintaining a project that use storybook and when I import @storybook/react node typings are loaded and it trigger this problem.

I will be able to bypass the issue, but it would be nice to find a way to remove the /// <reference types="node" /> from @storybook/react/dist/client/preview/index.d.ts using __WebpackModuleApi.Module as suggested by @robbiespeed. I've tested it myself by changing the file in my node_modules and it worked.

[IvanovRoman]

You can remove node_modules/@types/node using .yarnclean. Inside the file line -> @types/node.

[nickbullock]

the same for angular, using 7.0.0-beta.46

  node_modules/@storybook/angular/dist/client/public-api.d.ts:2:23
    2 /// <reference types="node" />
                            ~~~~
    File is included via type library reference here.

@100terres hey what workaround helped you to avoid this issue?

hey @shilman the issue has been here for more than 2 years, and no posted workarounds for all builds so far. Can we remove has-workaround tag?

[dleavitt]

FWIW, this has been blocking my team's adoption of Storybook for a couple years now. This used to be a fairly common problem among typescript libraries, but storybook seems to be one of the last ones that still hasn't fixed it.

I don't think there's any good workaround, so would be great to at least remove the has workaround tag.

There are some obvious places where the node types are being intermingled with frontend types (see below) but not sure how deep it goes. https://github.com/storybookjs/storybook/blob/next/code/lib/types/src/modules/core-common.ts#L6-L7

LMK if I can assist.

[gburning]

In my case (using 7.0.5) this doesn't seem to come from Storybook directly but one (or more) of its dependencies. I'm also using vue3 rather than react.

As of now I haven't been able to find a workaround, so if there is one I would love to know how I can remove any and all node types from my frontend code.

[dleavitt]

Workaround for me has been to vendor the type definitions I need and avoid importing anything from @storybook/* in any of my stories. The CSF approach lets me get away with this; I haven't needed need any functionality from storybook in my stories, just types.