Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: csf-plugin fails to read stories with names not matching hardcoded regex #26905

Open
abiriadev opened this issue Apr 22, 2024 · 3 comments

Comments

@abiriadev
Copy link

abiriadev commented Apr 22, 2024

Describe the bug

If a user change stories option from main.ts config(https://storybook.js.org/docs/api/main-config-stories), the addon-docs can't detect the stories file anymore because csf-plugin assumes CSF file should match with the pattern which is hardcoded, means there is no way to configure it from outside.

const STORIES_REGEX = /(?<!node_modules.*)\.(story|stories)\.[tj]sx?$/;

To Reproduce

To reproduce, I simply added custom CSF patterns to main.ts.

const config: StorybookConfig = {
  // ...
  stories: ["../src/**/*.mdx", "../src/**/*.stories.@(js|jsx|mjs|ts|tsx)", "../src/**/*.custom-stories.@(js|jsx|mjs|ts|tsx)"],
  // ...
};

You can find reproduction code at here: https://github.com/abiriadev/sb-csf-plugin-regex

As a short summary, the JSDoc comment inside *.custom-stories.ts does not render, while the same comment inside *.stories.ts renders without any issue.

image

There is also Stackblitz URL for the same code:
https://stackblitz.com/github/storybookjs/sandboxes/tree/next/react-vite/default-ts/after-storybook?file=.storybook%2Fmain.ts

System

Storybook Environment Info:

  System:
    OS: Linux 6.8 Arch Linux
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
    Shell: 3.7.1 - /bin/fish
  Binaries:
    Node: 20.6.1 - /run/user/1000/fnm_multishells/123756_1713749574530/bin/node
    Yarn: 1.22.22 - /run/user/1000/fnm_multishells/123756_1713749574530/bin/yarn <----- active
    npm: 9.8.1 - /run/user/1000/fnm_multishells/123756_1713749574530/bin/npm
    pnpm: 8.10.2 - ~/.local/share/pnpm/pnpm
  npmPackages:
    @storybook/addon-docs: ^8.0.8 => 8.0.8
    @storybook/addon-essentials: ^8.0.8 => 8.0.8
    @storybook/addon-interactions: ^8.0.8 => 8.0.8
    @storybook/addon-links: ^8.0.8 => 8.0.8
    @storybook/addon-onboarding: ^8.0.8 => 8.0.8
    @storybook/blocks: ^8.0.8 => 8.0.8
    @storybook/react: ^8.0.8 => 8.0.8
    @storybook/react-vite: ^8.0.8 => 8.0.8
    @storybook/test: ^8.0.8 => 8.0.8
    eslint-plugin-storybook: ^0.8.0 => 0.8.0
    storybook: ^8.0.8 => 8.0.8
    storybook-addon-remix-react-router: ^3.0.0 => 3.0.0

Additional context

A quickfix I can currently come up with is, to add stories field to EnrichCsfOptions type and use that value instead of STORIES_REGEX (or use STORIES_REGEX as a fallback).

export interface EnrichCsfOptions {
disableSource?: boolean;
disableDescription?: boolean;
}

transformInclude(id) {
return STORIES_REGEX.test(id);
},

But it would be ideal for addon-docs to automatically extract stories field from main.ts, since @storybook/addon-essentials should work with zero-config.

@valentinpalkovic
Copy link
Contributor

Hi @abiriadev

Thank you for reporting the issue!

Would you be able to put a PR together?

@shilman
Copy link
Member

shilman commented Apr 28, 2024

@valentinpalkovic There are a variety of places where we hardcode the story suffix because it's hard to get the information out of main.js and into those parts of the code. Fixing this is a larger architectural issue.

In the meantime, please use the recommended story suffix and you won't have any problems.

@abiriadev
Copy link
Author

abiriadev commented Apr 30, 2024

@shilman cc @valentinpalkovic

Fixing this is a larger architectural issue.

I totally understand that it would be hard to refactor every hardcoded part of the entire codebase!

In the meantime, please use the recommended story suffix and you won't have any problems.

Regarding the "meantime," does this imply that there are plans to address this issue in the near future, perhaps by providing an API for plugins? Or is it not planned for the immediate future? If it's unplanned, I will close this issue for now. :)

Thank you always for dedicating time to this awesome project!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants