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]: UnhandledSchemeError with storyStoreV7 feature turned off #22091

Closed
vyprichenko opened this issue Apr 14, 2023 · 9 comments · Fixed by #22512
Closed

[Bug]: UnhandledSchemeError with storyStoreV7 feature turned off #22091

vyprichenko opened this issue Apr 14, 2023 · 9 comments · Fixed by #22512

Comments

@vyprichenko
Copy link

vyprichenko commented Apr 14, 2023

Describe the bug

I'm in a process of migration from Storybook 6.4.19 to 7.0.4. Previously I've updated Webpack from 4.44.2 to 5.78.0 and did not face any issues in my project (but without extensive testing, just compiled and checked stories rendering).

Now, thanks to comprehensive migration guide and auto-migration tools, I've almost completed Storybook v6 -> v7 process, but got stuck with an issue, strangely similar to the one, elder: #16365 (comment)

My problem is also related to storyStoreV7 feature flag.
Setting storyStoreV7: false breaks build process:

@storybook/cli v7.0.2

WARN The "@storybook/addon-mdx-gfm" addon is meant as a migration assistant for Storybook 7.0; and will likely be removed in a future version.WARN It's recommended you read this document:
WARN https://storybook.js.org/docs/react/writing-docs/mdx#lack-of-github-flavored-markdown-gfm
WARN
WARN Once you've made the necessary changes, you can remove the addon from your package.json and storybook config.
info Found existing addon "@storybook/addon-docs", skipping.
info Found existing addon "@storybook/addon-docs", skipping.
info => Serving static files from ./.\public at /
info => Starting manager..
WARN You (or an addon) are using the 'config' preset field. This has been replaced by 'previewAnnotations' and will be removed in 8.0  
info Addon-docs: using MDX2
info => Using implicit CSS loaders
info => Using default Webpack5 setup
<i> [webpack-dev-middleware] wait until bundle finished
99% end closing watch compilationWARN Force closed preview build
ModuleBuildError: Module build failed: c:\Users\Vyprich\source\repos\AvtoProStorybook\node_modules\webpack\lib\NormalModule.js:835
                                                                return callback(new UnhandledSchemeError(scheme, resource));
                                                                                ^

eposAvtoProStorybook: Reading from "C:UsersVyprichsource
eact" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "c:" URIs.

To Reproduce

This is a starter project, created from a "React v17 Webpack (TypeScript)" template:
https://stackblitz.com/edit/github-g9ilis?file=.storybook/main.ts

Minimal changes were made for reproduction:

  • Removed src/stories/Introduction.mdx file to be able to turn storyStoreV7 off with no worrying about MDX2 format.
  • Added features: { storyStoreV7: false } to Storybook config.
  • Fixed src/index.tsx from a starter template, which contains ReactDOM v18 API calls in a React v17 project.

Now this still perfectly works in stackblitz.com environment, but when I download the same project, install and run on a Windows machine yarn storybook breaks with an UnhandledSchemeError, as described above.

Worth mentioning that yarn build works without a problem on Windows too.

System

System:
  OS: Windows 10 10.0.22621
  CPU: (8) x64 Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
Binaries:
  Node: 16.20.0 - C:\Program Files\nodejs\node.EXE
  npm: 8.19.4 - C:\Program Files\nodejs\npm.CMD
Browsers:
  Chrome: 111.0.5563.148
  Edge: Spartan (44.22621.1555.0), Chromium (112.0.1722.39)
npmPackages:
  @storybook/addon-actions: ^7.0.4 => 7.0.4
  @storybook/addon-docs: ^7.0.4 => 7.0.4
  @storybook/addon-essentials: ^7.0.4 => 7.0.4
  @storybook/addon-knobs: ^7.0.0 => 7.0.0
  @storybook/addon-links: ^7.0.4 => 7.0.4
  @storybook/addon-mdx-gfm: ^7.0.4 => 7.0.4
  @storybook/addon-postcss: ^2.0.0 => 2.0.0
  @storybook/addons: ^7.0.4 => 7.0.4
  @storybook/react: ^7.0.4 => 7.0.4
  @storybook/react-webpack5: ^7.0.4 => 7.0.4

Additional context

My attention is drawn to the line "C:UsersVyprichsource ... eact". Debugging shows that issue originates from webpack/lib/NormalModule.js where loaders are applied. The process fails on @storybook/webpack module (no problem with other modules), and I can see that processResource callback is called with strange resourcePath argument value: "C:UsersVyprichsource\reposAvtoProStorybook\node_modules@storybook\react" which is obviously not correct, and "context" field of a loader context is filled with the same value. Example of the right path to another module (in the same build process) on my system is "C:\\Users\\Vyprich\\source\\repos\\AvtoProStorybook\\node_modules\\@storybook\\react\\preview.js-generated-config-entry.js".

Webpack treats "C:UsersVyprichsource..." module path like an URL with "c:" scheme and requires some special loader for it.

main.js (reduced):

export default {
    stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|ts|tsx)'],
    features: {
        storyStoreV7: false // works when "true"
    },
    addons: [
        '@storybook/addon-links',
        '@storybook/addon-essentials',
        '@storybook/addon-knobs',
        '@storybook/addon-docs',
        'storybook-addon-designs',
        '@storybook/addon-mdx-gfm'
    ],
    staticDirs: ['../public'],
    webpackFinal: async (config) => {
        config.module.rules.push({
            test: /\.less$/,
            use: [
                'style-loader',
                {
                    loader: 'css-loader'
                },
                {
                    loader: 'postcss-loader'
                },
                {
                    loader: 'less-loader'
                }
            ]
        });
        return config;
    },
    framework: {
        name: '@storybook/react-webpack5',
        options: {
            builder: { lazyCompilation: false }
        }
    },
    docs: {
        autodocs: true
    }
};

Any help would be appreciated, thanks!

@vyprichenko vyprichenko changed the title [Bug]: with storyStoreV7 feature turned off, Webpack fires UnhandledSchemeError [Bug]: UnhandledSchemeError with storyStoreV7 feature turned off Apr 14, 2023
@shilman
Copy link
Member

shilman commented Apr 15, 2023

This definitely looks like a windows-specific bug in our webpack implementation or its interactions with your configuration, and we'd love to debug it.

Do you a have a reproduction repo you can share? If not, can you create one? Go to https://storybook.new or see repro docs. Thank you! 🙏

@vyprichenko
Copy link
Author

This is really windows-specific, I've added reproduction steps above.

There is another one, actually. If you locally create a Storybook project with npx storybook@next sandbox command and select, let it be, "React 17 Webpack 5 (TS)" template, then the following folder structure is created by default: "react-webpack\17-ts\" (the whole point is in the windows-style backslash notation). This results in a babel-loader error, because \1 sequence in the path is treated like a deprecated octal escape sequence. Looks like an additional escaping is necessary. I just rename "17-ts" to "ts-17" :)

ModuleBuildError: Module build failed (from ./node_modules/babel-loader/lib/index.js):
SyntaxError: C:\Users\Vyprich\source\repos\sb7\react-webpack\17-ts\storybook-init-renderer-entry.js: The only valid numeric escape in strict mode is '\0'. (1:56)

> 1 | import 'C:\Users\Vyprich\source\repos\sb7\react-webpack\17-ts\node_modules\@storybook\react';
    |                                                         ^
    at instantiate (C:\Users\Vyprich\source\repos\sb7\react-webpack\17-ts\node_modules\@babel\parser\lib\index.js:653:32)

@MirKml
Copy link

MirKml commented Apr 18, 2023

same experience - with error like Webpack supports "data:" and "file:" URIs by default. You may need an additional plugin to handle "c:" URIs. as described in error placing.

@TheCryptos
Copy link

As @vyprichenko and @MirKml said, we got the same issues here into a monorepo environment (Turborepo)

@atanasov-deyan
Copy link

experiencing the same when trying to start a local build, will be following for a development

@TheWoodenMan
Copy link

Also have the same issue, bringing Storybook 6.4 to 7+

ModuleBuildError: Module build failed: c:\Users\andyn\Documents\github\pow_frontend\node_modules\webpack\lib\NormalModule.js:795
return callback(new UnhandledSchemeError(scheme, resource));

           ^

UnhandledSchemeError: Reading from "C:UsersandynDocumentsgithubpow_frontend
eact" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "c:" URIs.

@michens
Copy link
Contributor

michens commented May 6, 2023

For now, I'm able to work around this by updating webpackFinal in main.ts:

  webpackFinal: (config) => {
    const staticModules = config.plugins[0]['_staticModules'] as Record<string, string>;

    Object.entries(staticModules).forEach(([k, v]) => {
      if (/storybook-init-renderer-entry/.test(k)) {
        staticModules[k] = v.replace(/\\/g, '\\\\');
      }
    });

    return config;
  }

I would guess that a proper fix should be simple. I might have time to look next week if no one beats me to it

@shilman
Copy link
Member

shilman commented May 11, 2023

¡Ay Caramba!! I just released https://github.com/storybookjs/storybook/releases/tag/v7.1.0-alpha.16 containing PR #22512 that references this issue. Upgrade today to the @future NPM tag to try it out!

npx sb@next upgrade --tag future

@shilman
Copy link
Member

shilman commented May 12, 2023

¡Ay Caramba!! I just released https://github.com/storybookjs/storybook/releases/tag/v7.0.11 containing PR #22512 that references this issue. Upgrade today to the @latest NPM tag to try it out!

npx sb@latest upgrade

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

Successfully merging a pull request may close this issue.

8 participants