storybook: storybook@6 throws a core-js error

just a reminder that now that you published 6.0 officially, this is still a problem.

it is very awkward having to install core-js directly in each repo we use storybook for. do you have any suggested fix on your end for this? anything we can contribute to help?

Zoinks!! I just released https://github.com/storybookjs/storybook/releases/tag/v6.2.0-alpha.0 containing PR #13055 that references this issue. Upgrade today to the @next NPM tag to try it out!

npx sb upgrade --prerelease

Closing this issue. Please re-open if you think there’s still more to do.

For people still bumping into this, we’re blocked by babel/babel#12035

The problem is pretty well understood now and is on babel’s end of things. Workarounds may be possible but would be fairly complex and hacky so im hoping babel can just fix it on their end instead, or at least tell us how to.

Looks like that is being fixed at babel/babel-polyfills#40

edit:

this is being worked on in #13055

Simply install core-js dependecy npm i core-js

I can confirm the solution of @jefferscn . I simplified with this, but it is the same:

config.resolve.alias['core-js/modules'] = '@storybook/core/node_modules/core-js/modules'

 "webpackFinal": (config)=> {
    config.resolve.alias['core-js/modules'] =  path.resolve(
            __dirname,
            '..',
            'node_modules/@storybook/core/node_modules/core-js/modules'
        );
    return config;
  }

Adding code upside to main.js sovle my problem.

Also having this problem.

Based on https://github.com/storybookjs/storybook/issues/6204#issuecomment-478992364, I added this to my config and it’s resolving correctly now:

resolve: {
    alias: {
        'core-js/modules': path.resolve(
            __dirname,
            '..',
            'node_modules/core-js/modules'
        ),
    }
}

Note that this is pointing to the root node_modules/core-js folder in my project, not to one that’s bundled with anything else.

Can this be updated when it’s fully released?

@shilman Still not working for me for very weird reason. Running yarn storybook throws a bunch of errors about core-js polyfill. For example:

ERROR in ./.storybook/preview.js-generated-config-entry.js
Module not found: Error: Can't resolve 'core-js/modules/es.symbol' in ...
 @ ./.storybook/preview.js-generated-config-entry.js 3:0-36
 @ multi ./node_modules/@storybook/vue/node_modules/@storybook/core/dist/server/common/polyfills.js ./node_modules/@storybook/vue/node_modules/@storybook/core/dist/server/preview/globals.js ./.storybook/storybook-init-framework-entry.js ./node_modules/@storybook/addon-docs/dist/frameworks/common/config.js-generated-other-entry.js ./node_modules/@storybook/addon-docs/dist/frameworks/vue/config.js-generated-other-entry.js ./node_modules/@storybook/addon-links/dist/preset/addDecorator.js-generated-other-entry.js ./node_modules/@storybook/addon-actions/dist/preset/addDecorator.js-generated-other-entry.js ./node_modules/@storybook/addon-actions/dist/preset/addArgs.js-generated-other-entry.js ./node_modules/@storybook/addon-backgrounds/dist/preset/addDecorator.js-generated-other-entry.js ./node_modules/@storybook/addon-backgrounds/dist/preset/addParameter.js-generated-other-entry.js ./.storybook/preview.js-generated-config-entry.js ./.storybook/generated-stories-entry.js (webpack)-hot-middleware/client.js?reload=true&quiet=false&noInfo=undefined

I have to do the workaround in main.js with the following:

webpackFinal: (config) => {
    config.resolve.alias["core-js/modules"] =
      "@storybook/core/node_modules/core-js/modules";
    config.resolve.alias["core-js/features"] =
      "@storybook/core/node_modules/core-js/features";
    return config;
  },

This happens when I have core-js version specifically points to 2.6.9.

Problem for me was that I didn’t match the @babel/preset-env option corejs property version to the correct one.

package.json: "core-js": "^3.6.5",

The solution: .babelrc (or wherever your babel config lives)

[
	"@babel/preset-env",
	{
		"corejs": "3.6.5", <- make sure this version is the same as core-js version installed!
		...
	}
],

Hey, thanks for the continued work on this. Unfortunately, upgrading to 6.2.0-alpha.1 on a private repo didn’t fix the stories, we didn’t have any workarounds to remove. I’ll update here if I come up with a minimal repo that contains the issue.

The repository is a mix of JS/typescript, managed by yarn 2 (berry), and has core-js version 3.0.1 specified at the root level package.json. Most of the errors are of the form

Module not found: Error: Your application tried to access core-js, but it isn't declared in your dependencies; this makes the require call ambiguous and unsound.

Required package: core-js (via "core-js/modules/es.string.iterator")
// path to some internal code

I had to modify my .storybook/main.js file to:

    webpackFinal: async config => {
        return {
            ...config,
            resolve: {
                alias: {
                    'core-js/modules': '@storybook/core/node_modules/core-js/modules',
                    'core-js/features': '@storybook/core/node_modules/core-js/features',
                },
            },
        };

same got a bunch of error like Module not found: Error: Can't resolve 'core-js/modules/web.dom-collections.iterator' Module not found: Error: Can't resolve 'core-js/modules/es.symbol.iterator'

That workaround didn’t work for me, I needed to configure specific aliases in the main.js file for core-js modules with name conflicts:

const path = require('path');

module.exports = {
  "stories": [
    "../src/**/*.stories.mdx",
    "../src/**/*.stories.@(js|jsx|ts|tsx)"
  ],
  "addons": [
    "@storybook/addon-links",
    "@storybook/addon-essentials"
  ],
  webpackFinal: async (config, { configType }) => {
    config.resolve.alias = {
      ...config.resolve.alias,
      'core-js/modules/es6.object.keys': path.resolve(
        __dirname,
        '../node_modules/core-js/modules/es.object.keys',
      ),
      'core-js/modules/es7.object.get-own-property-descriptors': path.resolve(
        __dirname,
        '../node_modules/core-js/modules/es.object.get-own-property-descriptors',
      ),
      'core-js/modules/web.dom.iterable': path.resolve(
        __dirname,
        '../node_modules/core-js/modules/web.dom-collections.iterator.js',
      ),
      'core-js/modules': path.resolve(
        __dirname,
        '../node_modules/core-js/modules',
      ),
    }

    return config;
  },
}

Same here. Just set up a clean project with vue-cli, added storybook and storybook-docs. npm run storybook results in lots of Module not found: Error: Can't resolve 'core-js/modules/....

Also, I found another workaround: when using yarn pnp + workspaces, if core-js is available in the top level module but not in a sub-package, adding this line in the main.js file should work:

config.resolve.alias["core-js"] = path.dirname(require.resolve("core-js"));

(require.resolve("core-js") will return the path to the .../node-modules/core-js/index.js file in pnp, and then path.dirname(...) will return the path to core-js itself and thus when core-js/module will be required, it’ll indeed generate .../node-modules/core-js/module and not .../node-modules/core-js/index.js/module)

Good news update on https://github.com/storybookjs/storybook/issues/11255#issuecomment-741905199

I investigated this bug with @arcanis, who quickly identified the issue. We found the error was due to the fact that a dependency of the main application (the one using storybook) was in a separate yarn workspace that did not have core-js explicitly specified as a dependency.

Adding the same version of core-js as a dependency to that library workspace as the version in the main application (the one where storybook is explicitly used) fixes the issue (using Storybook 6.0.21).

Still broken.

similar issue, I already had core-js in my project, and upgrading to 3(which we’ve been meaning to do anyway) doesn’t seem to fix this issue.

I originally wrote https://github.com/ndelangen/corejs-upgrade-webpack-plugin to ‘solve’ this issue.

But I deprecated it, because it just adds other problems, see: https://github.com/storybookjs/storybook/issues/7445 and https://github.com/ndelangen/corejs-upgrade-webpack-plugin/issues/7

conflicting versions of corejs are the bane of my existence.

essentially, storybook’s generated output tries to require core-js for various polyfills.

im guessing because it is generated output and doesn’t “live” in the storybook directory (node_modules/@storybook), it will resolve the first available core-js from the top level rather than resolving it relative to storybook’s directory.

so if you have storybook in a project which already has a different version of core-js (not necessarily as a direct dependency, all sorts of other projects also depend on core-js), that one may be required by accident rather than the one storybook wants.

this means the paths fail to resolve if the two core-js versions are drastically different.

the workaround (npm i -D core-js) solves the problem because then your top-level core-js is the same version as the one storybook wants. the older version will have then been moved deeper to live alongside whatever was requiring it.

That workaround didn’t work for me, I needed to configure specific aliases in the main.js file for core-js modules with name conflicts:

const path = require('path');

module.exports = {
  "stories": [
    "../src/**/*.stories.mdx",
    "../src/**/*.stories.@(js|jsx|ts|tsx)"
  ],
  "addons": [
    "@storybook/addon-links",
    "@storybook/addon-essentials"
  ],
  webpackFinal: async (config, { configType }) => {
    config.resolve.alias = {
      ...config.resolve.alias,
      'core-js/modules/es6.object.keys': path.resolve(
        __dirname,
        '../node_modules/core-js/modules/es.object.keys',
      ),
      'core-js/modules/es7.object.get-own-property-descriptors': path.resolve(
        __dirname,
        '../node_modules/core-js/modules/es.object.get-own-property-descriptors',
      ),
      'core-js/modules/web.dom.iterable': path.resolve(
        __dirname,
        '../node_modules/core-js/modules/web.dom-collections.iterator.js',
      ),
      'core-js/modules': path.resolve(
        __dirname,
        '../node_modules/core-js/modules',
      ),
    }

    return config;
  },
}

I have the same problem with you. You can try to add the option corejs: 3 with @babel/preset-env config in your .babelrc file and this works for me.

[
    "@babel/preset-env",
    {
      "modules": false,
      "targets": {
        "browsers": ["iOS >= 9"]
      },
      "useBuiltIns": "usage",
      "corejs": 3
    }
  ]

Also, I found another workaround: when using yarn pnp + workspaces, if core-js is available in the top level module but not in a sub-package, adding this line in the main.js file should work:

config.resolve.alias["core-js"] = path.dirname(require.resolve("core-js"));

(require.resolve("core-js") will return the path to the .../node-modules/core-js/index.js file in pnp, and then path.dirname(...) will return the path to core-js itself and thus when core-js/module will be required, it’ll indeed generate .../node-modules/core-js/module and not .../node-modules/core-js/index.js/module)

dirname was the magic I needed, thanks!

the previous problem with __webpack_require__ feels like its another issue.

somehow the webpack overrides conflicting maybe, its difficult to reproduce that one for sure. @uriklar if you could throw together a test repo which reproduces that problem, that’d be a big help. a minimal reproduction, trying to strip away as much as you can without making the problem go away.

same for you @henriquez , if you can reproduce it in a repo somewhere we can try debug a bit

This release has finally fixed it for our component library’s Storybook - thanks!

@shilman I just upgraded my Ember Addon with the pre-release version and it all works!

I was able to fix this by adding

"resolutions": {
    "**/core-js": "^3.6.5"
}

to my package.json, as described in #8267.

I was running into this problem on 6, downgraded to 5.3, hit another version of this issue after a while, then found & implemented the fix. I figured I might as well try the upgrade back to 6, and thankfully it still works.

All of the responses to add fields to the Webpack config did not work for me, but this obviously did.

I’m using Gatsby, and evidently there is one core-js@^2.4.0 dependency buried deep inside:

npm ls core-js

└─┬ gatsby@2.24.58
  ├── core-js@3.6.5  deduped
  └─┬ gatsby-cli@2.12.96
    └─┬ yurnalist@1.1.2
      └─┬ babel-runtime@6.26.0
        └──  core-js@^2.4.0

Adding the resolutions field does technically break the core-js dependency for that Gatsby / babel-runtime dependency (the tree now says UNMET DEPENDENCY next to core-js@^2.4.0), but I haven’t seen an issue yet.

no worries ill get on discord soon, wasn’t aware there was a storybook one 👍

@43081j happy to chat about a solution to this, are you on the storybook discord? https://discord.gg/7yKH3EU

I have the same problem. I set a breakpoint on the webpackFinal method, but it did not trigger. I suspect that the change here caused this problem, which was good before 6.0.0 beta14.