[Bug]: Unable to import 'rfc4648'

[Marklb]

Describe the bug

I have a dependency using the "rfc4648" package and none of my stories will work if I have that dependency imported anywhere. I am trying to figure out what about how Storybook is building the project causes that package to not work, but hoping someone more familiar with the build process can help find the problem faster.

The following is the error in the console, but I provided a Stackblitz repro with just one simple Component and Story that reproduces the issue.

TypeError: Cannot read properties of undefined (reading 'base16')
    at ./node_modules/rfc4648/lib/index.mjs (app-example-stories.iframe.bundle.js:256:66)
    at __webpack_require__ (runtime~main.iframe.bundle.js:28:33)
    at fn (runtime~main.iframe.bundle.js:322:25)
    at ./src/app/example.component.ts (app-example-stories.iframe.bundle.js:37:65)
    at __webpack_require__ (runtime~main.iframe.bundle.js:28:33)
    at fn (runtime~main.iframe.bundle.js:322:25)
    at ./src/app/example.stories.ts (app-example-stories.iframe.bundle.js:15:76)
    at __webpack_require__ (runtime~main.iframe.bundle.js:28:33)
    at fn (runtime~main.iframe.bundle.js:322:25)
    at main.iframe.bundle.js:265:10

To Reproduce

https://github.com/Marklb/sb-repro-22542

https://stackblitz.com/edit/github-qjqvmy-hdq5tc?file=src%2Fapp%2Fexample.component.ts,package.json

System

The repro sandbox and Stackblitz uses Storybook `7.0.10`.

Environment Info:

  System:
    OS: Windows 10 10.0.19045
    CPU: (8) x64 Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
  Binaries:
    Node: 16.19.0 - C:\Program Files\nodejs\node.EXE
    npm: 8.19.3 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (113.0.1774.35), ChromiumDev (115.0.1843.0)
  npmPackages:
    @storybook/addon-essentials: ^7.0.10 => 7.0.11
    @storybook/addon-interactions: ^7.0.10 => 7.0.11
    @storybook/addon-links: ^7.0.10 => 7.0.11
    @storybook/angular: ^7.0.10 => 7.0.11
    @storybook/blocks: ^7.0.10 => 7.0.11
    @storybook/testing-library: ^0.0.14-next.2 => 0.0.14-next.2

Additional context

No response

[fhaag]

Sounds like my recent question "Storybook fails with "Cannot read properties of undefined (reading 'base16')" for some components" on Stack Overflow, possibly related to angular-auth-oidc-client, which in turn uses rfc4648.

[Adrii77]

Same issue here... :/

[Marklb]

I haven't narrowed down what is happening exactly, but I have found that if I remove the "exports" property from node_modules/rfc4648/package.json then my code works. The exports property for that project is:

"exports": {
  ".": {
    "types": "./lib/src/index.d.ts",
    "import": "./lib/index.mjs",
    "require": "./lib/index.js"
  },
  "./package.json": "./package.json"
},

In the __webpack_require__ function, with the "exports" property the project is trying to resolve node_modules/rfc4648/lib/index.mjs, but without "exports" it resolves node_modules/rfc4648/lib/index.js and the .js file works. I don't know what is different in Storybook and Angular's config to cause it to not work, yet.

I am also having the problem with the angular-auth-oidc-client package, but I was able to reproduce it with just the rfc4648 package that it uses, so I didn't consider it to be an angular-auth-oidc-client issue.

[Marklb]

I found a rule in Storybooks webpack config that I can remove and the error doesn't happen.

storybook/code/lib/builder-webpack5/src/preview/iframe-webpack.config.ts

Lines 287 to 290 in 3aba9cf

	{
	test: /\.m?js$/,
	type: 'javascript/auto',
	},

I am not sure why that rule is there. At least for Angular, I assume all the necessary Typescript rules are already being added by it, so my current workaround is to remove that rule.

This may break something that I just haven't noticed, yet, but my current workaround is to filter out the rule in webpackFinal.

// main.js

module.exports = {
  ...,
  webpackFinal: config => {
    config.module.rules = config.module.rules.filter(rule => !(rule.type === 'javascript/auto' && rule.test?.toString() === /\.m?js$/.toString()))
    return config
  }
}

[Marklb]

@ndelangen It looks like #18534 added

storybook/code/lib/builder-webpack5/src/preview/iframe-webpack.config.ts

Lines 287 to 296 in 3aba9cf

	{
	test: /\.m?js$/,
	type: 'javascript/auto',
	},
	{
	test: /\.m?js$/,
	resolve: {
	fullySpecified: false,
	},
	},

The comment on that commit references a Stackoverflow answer that says to add these two rules. Looking at the comment it references, the first rule seems to only be necessary for being able to use the second rule in some cases. It there a reason we need that first rule or would have a problem by removing it when building Angular?

[ndelangen]

If angular wants something else, that's fine with me, but we should consult the @storybookjs/angular team.
Perhaps this is something @valentinpalkovic or @kroeder would know best?

The rule could be removed by the angular framework.

[kroeder]

I'm actually not sure. According to my short research, the second rule should be just fine without the first rule 🤔 (the StackOverflow comment mentions as well)

I had to add a $ at the end of the regex. Also, the first rule is not needed. (comment)

 { 
   test: /\.m?js$/, 
   resolve: { 
     fullySpecified: false, 
   }, 
 }, 

[dylannnn]

I found a rule in Storybooks webpack config that I can remove and the error doesn't happen.

storybook/code/lib/builder-webpack5/src/preview/iframe-webpack.config.ts

Lines 287 to 290 in 3aba9cf

	{
	test: /\.m?js$/,
	type: 'javascript/auto',
	},

I am not sure why that rule is there. At least for Angular, I assume all the necessary Typescript rules are already being added by it, so my current workaround is to remove that rule.

This may break something that I just haven't noticed, yet, but my current workaround is to filter out the rule in webpackFinal.

// main.js

module.exports = {
  ...,
  webpackFinal: config => {
    config.module.rules = config.module.rules.filter(rule => !(rule.type === 'javascript/auto' && rule.test?.toString() === /\.m?js$/.toString()))
    return config
  }
}

After filter out the rules, the issue is gone.

[swansontec]

I have published rfc4648 v1.5.3, which should contain a fix for this issue. Upgrading the dependency may be all you need.

[Marklb]

Just updated my dependencies and the problem does appear to be fixed.