Next.js: Avoid interfering with the svgr loader #27198
Conversation
|
@valentinpalkovic as part of this, should I update the svgr example so that it checks for all image rules rather than the first one? |
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 8a84014. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 1 targetSent with 💌 from NxCloud. |
valentinpalkovic
added
bug
patch:yes
|
Thank you so much for putting this together that fast! If you want to adjust the docs, it would be appreciated. Otherwise, I'll take care of it together with @jonniebigodes. |
|
I'll leave it for you and @jonniebigodes |
|
@valentinpalkovic FWIW, when I copy the Typescript version of the example into our project, we have a couple TS errors. We have The line that has const imageRule = config.module.rules.find((rule) => rule?.['test']?.test('.svg'));Has the following error And the line that has imageRule['exclude'] = /\.svg$/;Has the following error: Replacing that code with your suggestion, this is one way to make (strict) TS happy: config.module.rules.forEach((rule) => {
if (
typeof rule === 'object' &&
rule?.['test'] instanceof RegExp &&
rule['test'].test('.svg') &&
typeof rule.issuer === 'object' &&
'not' in rule.issuer &&
rule.issuer.not instanceof RegExp &&
rule.issuer.not?.test('.css')
) {
rule['exclude'] = /\.svg$/;
}
return rule;
});🥴 There's probably a better/more elegant way to do this, but I also wonder if the logic should be more lenient with the |
|
I agree. Being fully TypeScript compliant is sometimes really horrible. Let me know if you find a more elegant solution to this issue. |
Next.js: Avoid interfering with the svgr loader (cherry picked from commit 84fa690)
Next.js: Avoid interfering with the svgr loader (cherry picked from commit 84fa690)
github-actions
bot
added
the
patch:done
Closes #27195
What I did
This is a followup to #27093 as it causes issues for anyone who has followed the example for adding SVGR support to Storybook. Instead of adding a
testto the raw loader, this PR usesexcludeso the rule doesn't apply to__barrel_optimize__requests.Checklist for Contributors
Testing
As I mentioned in #27093, if there's a good way to cover this scenario as part of an integration and/or e2e test, please let me know.
The changes in this PR are covered in the following automated tests:
Manual testing
There is a reproduction in #26991 (https://github.com/11bit/next-storybook-import-raw-bag) that could be used to confirm this story loads with these changes.
Documentation
MIGRATION.MD
Checklist for Maintainers
When this PR is ready for testing, make sure to add
ci:normal,ci:mergedorci:dailyGH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found incode/lib/cli/src/sandbox-templates.tsMake sure this PR contains one of the labels below:
Available labels
bug: Internal changes that fixes incorrect behavior.maintenance: User-facing maintenance tasks.dependencies: Upgrading (sometimes downgrading) dependencies.build: Internal-facing build tooling & test updates. Will not show up in release changelog.cleanup: Minor cleanup style change. Will not show up in release changelog.documentation: Documentation only changes. Will not show up in release changelog.feature request: Introducing a new feature.BREAKING CHANGE: Changes that break compatibility in some way with current major version.other: Changes that don't fit in the above categories.🦋 Canary release
This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the
@storybookjs/coreteam here.core team members can create a canary release here or locally with
gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>