Open sokra opened 2 years ago
This issue had no activity for at least three months.
It's subject to automatic issue closing if there is no activity in the next 15 days.
bump
Issue was closed because of inactivity.
If you think this is still a valid issue, please file a new issue with additional information.
/cc @TheLarkInn We have this, so I just will add more things from css-loader/etc so we can see our progress
@alexander-akait I'm wondering how experiments.css working with the current css-loader ecosystem,for example https://github.com/seek-oss/css-modules-typescript-loader which consume the result of css-loader, but since experiments.css handle css after loader there're no chances for other loader to get css-module intermediate result, will experiments.css expose some hooks for this scenarios?
@alexander-akait I'm wondering how experiments.css working with the current css-loader ecosystem,for example https://github.com/seek-oss/css-modules-typescript-loader which consume the result of css-loader, but since experiments.css handle css after loader there're no chances for other loader to get css-module intermediate result, will experiments.css expose some hooks for this scenarios?
It doesn't work, css-loader and etc output a warning and do nothing. Anyway you can set type: ""javascript/auto"
and css-loader will work as before.
css-modules-typescript-loader
should be rewritten, it should be a plugin which takes CSS dependecies and modify generated code, it is no hard to implement, we can't adopt it and make compatibility, because css-modules-typescript-loader
uses generated JS by css-loader
, I don't know why it was implemented in such way, because it should be just an option for css-loader (just a custom function that postprocess exports).
The main idea of the new CSS pipeline - avoid generate JS and CSS multiple times, like we have right now
i do agree this should be implemented as plugin and no need to be compatible,how this plugin should be implemented becomes a problem,should this plugin consume css dep directly and do the same codegen logic as internal css codegen or should it just consume the intermediate result of intetnal css module processing
@hardfist
i do agree this should be implemented as plugin and no need to be compatible,how this plugin should be implemented becomes a problem,should this plugin consume css dep directly and do the same codegen logic as internal css codegen or should it just consume the intermediate result of intetnal css module processing
Yeah, we need to think about it, maybe we can introduce extra hooks to simplify this process, let's keep this here, We wanted to finish normal CSS support firslty and then I will think about it and put in our test cases a simplified example
I'm not sure whether all the options in css-loader and mini-css-extract-plugin will be supported in experiments.css, and we're migrating some applications from css-loader & mini-css-extract-plugin to experiments.css and missing some functionalities, so maybe I can track these in this issue or file separate issue?
if these functionalities are accepted we're willing to implement it for webpack
from https://github.com/webpack/webpack/issues/17700
It's unclear how to get the old extract
+ css-loader
setup: generate CSS files and do nothing else.
Currently it appears that experiments.css: true
generates the CSS files but also tries to load them, causing this error in my environment (web extension)
Uncaught TypeError: Failed to execute 'getComputedStyle' on 'Window': parameter 1 is not of type 'Element'.
at loadCssChunkData (refined-github.js:28644:21)
Which wasn't the case with the following configuration:
module: {
rules: [
{
test: /\.css$/,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
],
},
]
},
plugins: [
new MiniCssExtractPlugin(),
],
getComputedStyle
@fregante This might help you https://github.com/webpack/webpack/issues/16147#issuecomment-1583612714
No, webpack should not run any JavaScript if I ask it to generate a CSS file, so that isn't useful for this scenario.
Dear @sokra ,
I am Sushil SIngh. I'm writing to express my interest in contributing to the ongoing enhancement of Webpack's CSS capabilities, specifically Issue #14893 . I have reviewed the provided information and believe that I possess the necessary skills to make meaningful contributions to the project.
Hi,
there is any way to opt-out from the css variables rewrite and use localIdentName
only for css classes?
Another thing, is possible to ignore the url()
s, like with the url option of css-loader?
@francescocaveglia
there is any way to opt-out from the css variables rewrite and use localIdentName only for css classes?
can you provide why you need disable it?
Another thing, is possible to ignore the url()s, like with the url option of css-loader?
Hi @alexander-akait
can you provide why you need disable it?
In our project we use an external web components library and we have many customizations made through CSS variables.
Having them rewritten means we should wrap every instance with :global
It is possible to configure it to ignore "every resource inside a url()
call"?
Thanks
In our project we use an external web components library and we have many customizations made through CSS variables. Having them rewritten means we should wrap every instance with :global
Do you have :local
? We can make it an option for this
It is possible to configure it to ignore "every resource inside a url() call"?
You can use this as function, what setup do you have for css-loader
?
Could this support request be moved out of here? It’s off topic, I’m following the issue to get updates about native CSS support
Current State: opt-in via
experiments.css: true
Explainer (not everything is implemented yet):
experiments.css: true
enables the native css support in webpackimport "./style.css"
: Attaches the stylesheet to the document as side effect of importing.@import
andurl()
are resolved.import stylesheet from "./style.css" asset { type: "css" }
: Exports the unattached stylesheet as default export. You can adopt it according to the spec.@import
is not allowed (yet), buturl()
will be resolved.import { main } from "./style.module.css"
: Like A, but renames all css classes, keyframes and css variables and exports the new names. Global selectors are only allowed with explicit:global
selector prefix.@import
andurl()
are resolved.new URL("./style.css", import.meta.url)
: Gives an URL to a stylesheet including all styles.@import
andurl()
are resolved.import { main } from "./style.module.css"
: Like C, but for the node.js target. It generates a JSON module with the exports from the CSS.output.cssFilename
andoutput.cssChunkFilename
allows to configure the filename template for css files. By default it copiesfilename
resp.chunkFilename
with extension changed to.css
@import "..."
in the output css filestype: "css/..."
in rules to apply loader results as css. e. g. for Sass support.mini-css-extract-plugin
andcss-loader
Implemented:
@import url("...");
@import "...";
url()
output.cssFilename
css-import
asset
:export
blocksimage-set()
@import url("...") layer(test);
@import url("...") supports(...);
@import url("...") media query;
#import
and make them externalstyle
resolution in package.json and test it + test support loader usagefetchpriority
publicPath
for assets modules inside CSS files@import
Not implemented/tested, but Planned (ordered by priority):
type: css
enables CSS modules support (i.e. for CSS without CSS modules you need settype: "css/global"
), which might be a bit confusing for developers, because some developer just want to use pure CSS and parsing CSS modules can affect on perf, I think we should do:type: "css/auto"
- enable/disable CSS modules based on path and default type for CSS?type: "css"
- no CSS modules and don't try to parse CSS modules thingstype: "css/module-local"
- CSS modules withlocal
modetype: "css/module-global"
CSS modules withglobal
modeimage()
src()
:import
blockscomposes: xxx
composes: xxx from "..."
composes: xxx from global
var(xxx from "...")
var(xxx from global)
@import
/* webpackIgnore: true */
forurl()
/image-set()
?hash
generation in --webpack-main when you have multiple same modulesurl()
in css leaves an asset JS Module in js chunkimport()
generates prefetch/preload runtime for JSurl("font.svg#svgFontName")
created invalid filename