Support `/** webpackIgnore: true */`

[slorber]

• Operating System: MacOs
• Node Version: 14
• NPM Version: 6
• webpack Version: 4.44.1
• css-loader Version: 5.0.1

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 to url('/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

[alexander-akait]

What is use case? webpack allows to resolve /fonts/font.eot, you just need setup resolve.roots (by default is is context).

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')

[slorber]

What is use case?

Retro compatibility.
It used to not be resolved before this upgrade (https://github.com/facebook/docusaurus/pull/4081/files) and now it is.

The main answer why it should be not resolved?

To keep the behavior as it was before.
We are an opiniated mainstream doc tool used by a lot of people, many of them are not frontend devs (technical writers, academics).
Asking our users to use custom webpack config, inline file loader syntax or anything makes the upgrade to our next version more complicated.

---

I'll try to figure out a solution so that moving from non-required to required does not need any change for our users, resolve.roots + default fonts file-loaders might do the trick in this case.

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 /* webpackIgnore: true */

Thanks

[alexander-akait]

Supporting /* webpackIgnore: true */ is not a hard task.

We are an opiniated mainstream doc tool used by a lot of people, many of them are not frontend devs (technical writers, academics).

I know well docusaurus ⭐

But can you clarify what do you mean To keep the behavior as it was before.? Why developers write /fonts/font.ttf? Why do not provide good (resolvable) URL to fonts? Don't forget webpack has resolve.roots, so resolving is not the problem, you can have multiple roots paths

[slorber]

👍

To give full context, I'm working on testing our upcoming canary release on a site that requires LTR support:

• https://github.com/massoudmaboudi/datagit_v2.docusaurus
• https://datagit.ir/

After upgrading Docusaurus from @latest to local symlinks, I saw the site failed to build due to fonts:

https://github.com/massoudmaboudi/datagit_v2.docusaurus/blob/master/src/css/custom.css#L196

@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 resolve.roots + fonts file-loader would let the user upgrade without modifying his CSS

[alexander-akait]

So something has changed, not sure exactly when/how :)

in v4 we added ability to resolve server relative url and absolute paths, so /images/image.png is now consider as resolvable

[slorber]

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

[alexander-akait]

Yep, let's do it, but if no problemы right now I will reduce priority of this

[eytienne]

in v4 we added ability to resolve server relative url and absolute paths, so /images/image.png is now consider as resolvable

Is this working? Because I have Error: Can't resolve '/business-specific-image/' in '/.../scss' while having this style:

#business-specific {
  /* webpackIgnore: true */
  background-image: url("/business-specific-image/");

Is my url breaking rules to be resolved? And why the magic comment seems ignored?

[alexander-akait]

You need to update css-loader, please check it