next-image-loader-stub error when trying to use @svgr/webpack for svg importing about storybook-addon-next HOT 4 CLOSED

Thanks for opening up the issue! I'd be happy to look into this.

ref #56

from storybook-addon-next.

TLDR: add an exclude rule to the existing image rule

// .storybook/main.js
module.exports = {
  // other config omitted for brevity
  webpackFinal: async config => {
    // add these lines
    const imageRule = config.module.rules.find(rule => rule.test.test('.svg'))
    imageRule.exclude = /\.svg$/

    // add your rule as normal
    config.module.rules.push({
      test: /\.svg$/,
      use: ['@svgr/webpack']
    })

    return config
  }
}

I was able to replicate the issue and I see why it is happening.

As you correctly suspected, the addon adds its own loader rules and doesn't consider that the developer might add their own rules, thus creating this conflict.

The workaround above is to loop over the webpack rules, find the one this addon adds for images, replace its test regex to be the current regex it uses minus the .svg file extension or add an excludes field on the rule excluding .svg. This seems to be the conventional storybook wisdom to handle custom webpack configs, the way the rest of the internet seems to handle making custom webpack rules work with storybook, and the approach that I've found to be the best solution.

Here are some links I used to help make the above judgement:

• https://medium.com/@derek_19900/config-storybook-4-to-use-svgr-webpack-plugin-22cb1152f004
• https://github.com/Negan1911/storybook-svgr-react-component/blob/master/index.js
• https://stackoverflow.com/questions/61498644/storybook-failed-to-execute-createelement-on-svg-files-using-svgr-webpack
• https://duncanleung.com/import-svg-storybook-webpack-loader/

I'm considering the following paths forward as solutions to this issue:

1. The workaround above should be considered the golden path for making custom webpack changes to storybook
   • pros
     • This is closest to the "storybook" way of modifying webpack configs since it uses the same patterns the rest of the storybook ecosystem uses
     • Allows current documentation and solutions produced by google searching to inadvertently also apply to this addon (as is the case with getting svgr support)
     • Doesn't require any changes to this code base
     • Doesn't make this addon try to do too much
       • For example, an approach that includes special code to handle the edge case of adding a specific package can lead to an inflexible addon that is hard to maintain and hard get to work with other packages, paradigms, edge cases, etc
     • Is an approach that applies not only to getting svgr to work, but also any other custom webpack configs
     • Better aligns with the philosophy of this addon: if Next.js includes it out of the box, then this addon does too. Since Next.js doesn't include svgr out of the box and instead just makes it easy to add, then follows that this addon should not include svgr out of the box and instead make it easy to add
   • cons
     • It requires the developer to modify and understand how webpack configs work (which I have learned as part of the making of this addon can be annoying)
     • It isn't a "works out of the box" experience
2. Add special handling of this edge case within this addon for svgr support (e.g. add an addon option to indicate that svgr is being used, an option to pass in a custom image regex, etc)
   • pros
     • Svgr is a popularly used tech alongside nextjs to the point that the nextjs webpack config has special handling of packages like it so getting this to work out of the box potentially would make a lot of developers happy
     • Users of this addon have one less reason to not care about webpack configs
   • cons
     • Trying to handle all of the permutations of all the packages the users of this addon might want to include with this addon will get unwieldy
     • Today, svgr is the hot svg library, but what about tomorrow? How does this addon plan to evolve over time if it tries to support every package out of the box?
3. Pass storybook's webpack config into the webpack function in next.config.js
   • pros
     • Only one place to configure webpack
     • Potentially has a "works out of the box" like experience for simple configs
   • cons
     • Storybook and nextjs webpack configs might diverge too greatly for this to work well
     • It breaks the "storybook" way of modifying webpack configs by forcing the developer to modify the webpack config both in next.config.js and .storybook/main.js
     • It might work in simple cases, but probably leads to big problems once the next.config.js's webpack config gets too custom
     • It would include any third party webpack modifications here too and they weren't designed to work with storybook's webpack config
     • It feels like we are breaking/abusing the contract/intent of next.config.js's webpack function. I feel like it should only be used for Next.js specific customization whereas .storybook/main.js should be used for storybook specific customization
     • Increases the complexity of the code
     • Likely leads to unwanted surprises when developers figure out that we are using the webpack function in next.config.js (I just feel that this isn't intuitive to expect, feel free to disagree)

I'm leaning towards the first option, but I'm going to sleep on it to make sure I'm doing this with a clear mind. I'm very open to any opinions or ideas anyone wants to offer! :)

from storybook-addon-next.

Hi @RyanClementsHax, thanks for the very thorough info! I can confirm I've had success and totally agree with your first option and so far it has been working great!! 😃 With this in mind I think we can close this issue with this workaround cause it fulfils any specific Webpack setup there might be, it just needs to be replicated to the main.js which has always been the case.

Thank you so much for investing time in this, I really appreciate it and all the hard work you've put in on this addon, it's been a real treat to use!

from storybook-addon-next.

Hi @RyanClementsHax, thanks for the very thorough info! I can confirm I've had success and totally agree with your first option and so far it has been working great!! 😃 With this in mind I think we can close this issue with this workaround cause it fulfils any specific Webpack setup there might be, it just needs to be replicated to the main.js which has always been the case.

Thank you so much for investing time in this, I really appreciate it and all the hard work you've put in on this addon, it's been a real treat to use!

I'm really glad this helped out! I really appreciate the happy feedback. I'm glad the workaround worked for you! Let me know if you run into any other problems.

from storybook-addon-next.