build-storybook fails with storybook-addon-jsx

[nicolaskruchten]

When I activate https://github.com/Kilix/storybook-addon-jsx and run build-storybook I get the following error:

Building storybook ...
Failed to build the storybook
static/preview.1df973a972c249728195.bundle.js from UglifyJs
Invalid assignment [static/preview.1df973a972c249728195.bundle.js:44048,34]

It seems like Uglify is failing on some ES6 input, specifically an arrow function (that's what's on line 44048 in that JS file, and it's the first line where an arrow function appears).

To reproduce:

1. clone this: https://github.com/plotly/react-pivottable/tree/jsx-addon-bug
2. npm install
3. npm run build-storybook

I've filed an issue in the addon repo (storybookjs/addon-jsx#16), but I wonder if this isn't a framework problem...?

[tmeasday]

@nicolaskruchten I'd say the problem is this: algolia/react-element-to-jsx-string#140

[tmeasday]

I suspect it will get fixed by #1733

[tmeasday]

An alternative (workaround) solution is to alter the webpack config to compile just the relevant node modules. This works:

      {
        test: /\.js$/,
        loader: 'babel-loader',
        include: /node_modules\/(stringify-object|get-own-enumerable-property-symbols)/,
      },

(I know all this because I ran into this bug in a different context just the other day, although not in storybook)

[nicolaskruchten]

Ah, thanks @tmeasday that's really helpful!

Question: when you say "alter the webpack config" which config do you mean? Do you mean via the "full control" mechanism here https://storybook.js.org/configurations/custom-webpack-config/ ?

[nicolaskruchten]

Ah, I see there's a solution with full-control mode here: #1570

[leetercola]

I tried the workarounds here and #1570 but they either break resolution, or loaders. I concur with the other discussion on 1570 why is there an uglify plugin against src and not babel parsed code? Either pull the plugin or pre parse it with babel before the uglify.

[Hypnosphi]

@leetercola the thing is that loaders (including babel-loader) don't process files from node_modules by default

[tmeasday]

I don't think you can selectively apply uglify, it will run over the whole webpack-ed bundle, which includes your code, and things from node_modules. As @Hypnosphi points out, typically you do not run babel over node_modules (because it'd be hella slow and is unnecessary).

Of course it's no longer true that it's unnecessary if people are going around publishing uncompiled ES6 packages that are not targeted at the browser. This is what's happening in this case. So my solution above is to tweak the webpack config to ask it to selectively apply babel inside node_modules.

@leetercola are you sure that you implemented what I was talking about above correctly? I have not solved this particular problem for storybook-build but I had the exact same problem in my app and the config above solved it.

[tmeasday]

Meanwhile I should add this whole situation is messed up and it should not be your responsibility to fix it.

It doesn't look like the original package author is likely to change his stance on pre-compiling his package, so I would say the next best solution in the short term is the author of storybook-addon-jsx (@Kilix) should figure out a way to depend on a pre-compiled version of react-element-to-jsx-string.

Otherwise, this should fix it eventually: #1733

[stale]

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 60 days. Thanks!

[stale]

Hey there, it's me again! I am going close this issue to help our maintainers focus on the current development roadmap instead. If the issue mentioned is still a concern, please open a new ticket and mention this old one. Cheers and thanks for using Storybook!