-
-
Notifications
You must be signed in to change notification settings - Fork 606
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
Support /** webpackIgnore: true */
#1256
Comments
What is use case? webpack allows to resolve The main answer why it should be not resolved? url('noRequire:/fonts/font.ttf') Sorry but it is broken CSS syntax and will be bad idea. I agree with: /* webpackIgnore: true */
url('/fonts/font.ttf') |
Retro compatibility.
To keep the behavior as it was before. I'll try to figure out a solution so that moving from non-required to required does not need any change for our users, Still think that being able to opt-out of require() with some kind of css inline syntax could be useful, and would be perfectly fine with Thanks |
Supporting
I know well But can you clarify what do you mean |
👍 To give full context, I'm working on testing our upcoming canary release on a site that requires LTR support: After upgrading Docusaurus from @font-face {
font-family: "Iran Sans";
font-style: normal;
font-weight: 100;
src: url("/fonts/IRANSans5.5/IRANSansWeb_UltraLight.eot"),
/* IE9 Compat Modes */
url("/fonts/IRANSans5.5/IRANSansWeb_UltraLight.eot?#iefix")
format("embedded-opentype"),
/* IE6-IE8 */ url("/fonts/IRANSans5.5/IRANSansWeb_UltraLight.woff2")
format("woff2"),
/* Super Modern Browsers */
url("/fonts/IRANSans5.5/IRANSansWeb_UltraLight.woff") format("woff"),
/* Modern Browsers */ url("/fonts/IRANSans5.5/IRANSansWeb_UltraLight.ttf")
format("truetype");
} Errors were related to inability to resolve at those paths + missing file-loaders for fonts (after paths are fixed). Yet the site worked fine before, as the CSS show unprocessed URLs that are correctly served: https://datagit.ir/styles.10a1b0ec.css So something has changed, not sure exactly when/how :) Currently trying to see if the |
in v4 we added ability to resolve server relative url and absolute paths, so |
thanks for the info ;) It seems resolve.roots is working for my usecase, so I'll let you decide if you want to implement the ignore comment |
Yep, let's do it, but if no problemы right now I will reduce priority of this |
/** webpackIgnore: true */
Is this working? Because I have
Is my url breaking rules to be resolved? And why the magic comment seems ignored? |
You need to update |
Checked, I was in 5.2.4 so up to date with this change and it neither works in 5.2.6. |
@eytienne please create reproducible test repo, we have strong tests on this |
Thank you, I fixed it trying to reproduce. It was because of postcss upstream removing comments with cssnano, the trick with |
Thank you @eytienne, saved me a lot of time! |
If anybody else runs into this, particularly if anybody else finds they can't use the If you're using a prefab Webpack config you'll need to find the relevant rule in the cssLoaderRuleReference.options.url = {
/**
* Do not process url() statements for certain files in assets/.
*
* @param {string} url Path to asset referenced via url().
* @returns {boolean} Whether to process with loader.
*/
filter( url ) {
return ! /assets\/(your|pattern|here)/.test( url );
},
}; |
Feature Proposal
Allow urls to not be converted to require() calls, on a per-url basis.
url('noRequire:/fonts/font.ttf')
should just be converted tourl('/fonts/font.ttf')
without any processing(noRequire is maybe not a good name but you understand the idea).
I wasn't able to find in a doc to escape on a per-url basis from this url->require conversion behavior
Feature Use Case
I'm the maintainer of https://github.com/facebook/docusaurus and we are doing preparatory work to upgrade to Webpack 5, that will impact thousands of doc sites.
We used css-loader@3, and some users had
url("/fonts/font.eot")
, and it did not get processed before.After upgrading to css-loader@5 (PR: facebook/docusaurus#4081)
for some reason an URL that worked before now fails.
url("/fonts/font.eot")
used to work, but does not anymore, as it's converted to a require call.url("!!file-loader!/static/fonts/font.eot")
is a good workaround, but I don't feel like we should recommend that to our large user-base, that are not even all frontend developers (we are a documentation tool)I don't particularly want to disable fully this URL => require() conversion, as I think it's better to let webpack process/hash assets for caching purpose, just having a convenient escape hatch to fallback to no processing at all.
Does it make sense?
Note: it's not convenient for our users to customize the webpack config with site-specific rules
The text was updated successfully, but these errors were encountered: