Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestions #44

Open
hamfz opened this issue Apr 28, 2020 · 1 comment
Open

Suggestions #44

hamfz opened this issue Apr 28, 2020 · 1 comment

Comments

@hamfz
Copy link

hamfz commented Apr 28, 2020

These are more or less issues/suggestions that I thought may be useful feedback. There may be a config way around these, but I want to share how I solved them.

  1. By default it seems like the plugin configs Webpack to use both url-loader and svgr/webpack. Would be nice to be able to opt into or out of the url-loader.

  2. There is either a bug or "feature" of Webpack currently where the presence of an issuer rule will prevent Webpack from using a loader on files dynamically imported, since we load a folder of filename.svg files through require.context, the default gatsby-plugin-svgr loader config would not work. (Rule with issuer is not applied when importing via require.context webpack/webpack#9309)

In either case, I got around both of these issues by more manually configuring the gatsby-node.js webpack config. However, it seems a bit round about -- I may not even need to use this plugin given the amount of webpack config changes I am making to the default config provided.

@coreyward
Copy link
Collaborator

I think we'd be open to a PR that makes presence of the url-loader configurable, provided it remains on by default.

As for the conflict between dynamic imports and issuers, I don't think there's any other way for this plugin to exclude a React-specific loader (svgr) from being used when importing in CSS files, so yes, it seems like in this scenario a custom configuration would likely be better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants