storybook
storybook copied to clipboard
@storybook/react (and possibly others) require node types
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.
@gaetanmaisse can you lend a hand here?
Sure! I will take a look at that as part of the dependency cleaning work I planned.
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
@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.
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.
You can remove node_modules/@types/node using .yarnclean. Inside the file line -> @types/node.
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?
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.
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.
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.