css-loader: css-loader Does not honor/inherit postcss-loader syntax
Bug report
Actual Behavior
I built a postcss syntax (parser, tokenizer, stringifier, the whole works) so that I can get postcss to recognize hubl syntax (hubspot) in css.
Hubl is basically Jinja and on hubspot is allowed to be used in CSS files.
If I use my postcss syntax with pure postCSS (no webpack) everything works as expected. However, when I wrap it all in webpack and use the postcss loader it appears to run postcss twice.
The first pass is the postcss-loader(which works as expected) the second pass is the css-laoder(which doesnt inherit the postcss-syntax specified) and fails.
Expected Behavior
styles.css (pre-run)
{% if x %}
.test{
text-align: center;
}
{% endif %}
styles.css (post-run)
{% if x %}
.test{
text-align: center;
}
{% endif %}
Actual Result
/*{% if hubl statement %}*/.test{
text-align: center;
}
/*{% endif %}*/
Console Log of flow:
----------- Post CSS Loader Running -------------
Running new parser ==========================+
HUBL FIRE -------------------
HUBL FIRE -------------------
Hubl Stringify Running (from @spingroup/postcss-hubl/lib/stringifier.js)
Hubl Stringify Running
HUBL FIRE STRING start _-_---------------
HUBL FIRE STRING END _-_---------------
Hubl Stringify Running
Hubl Stringify Running
Hubl Stringify Running
HUBL FIRE STRING start _-_---------------
HUBL FIRE STRING END _-_---------------
----------- CSS Loader Running -------------
OG STRINGIFY (from node/postcss/stringifier.js)
OG STRINGIFY (from node/postcss/stringifier.js)
og-comment (from node/postcss/stringifier.js)
OG STRINGIFY (from node/postcss/stringifier.js)
OG STRINGIFY (from node/postcss/stringifier.js)
OG STRINGIFY (from node/postcss/stringifier.js)
og-comment (from node/postcss/stringifier.js)
How Do We Reproduce?
postcss.config.js
const HublSyntax = require('@spingroup/postcss-hubl/lib/hubl-syntax');
module.exports = {
syntax: HublSyntax,
mode: "production",
to: "./dist/main.css",
plugins: []
};
webpack.config.js
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const path = require('path');
module.exports = {
plugins: [
new MiniCssExtractPlugin({
filename: "[name].css",
}),
],
entry: {
'index': './src/index.js',
},
output: {
filename: '[name].js',
path: path.resolve(__dirname, 'dist'),
},
mode: 'production',
module: {
rules: [
// Relevant config for MiniCssExtractPlugin:
// (the order of `use` is important)
{
test: /\.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'postcss-loader',
],
},
],
},
};
Please paste the results of npx webpack-cli info
here, and mention other relevant information
System:
OS: macOS 11.5.2
CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
Memory: 196.41 MB / 16.00 GB
Binaries:
Node: 12.22.1 - ~/.nvm/versions/node/v12.22.1/bin/node
Yarn: 1.22.10 - ~/.nvm/versions/node/v12.22.1/bin/yarn
npm: 7.16.0 - ~/.nvm/versions/node/v12.22.1/bin/npm
Browsers:
Chrome: 95.0.4638.69
Firefox: 88.0.1
Safari: 14.1.2
Safari Technology Preview: 15.0
Packages:
css-loader: ^6.5.0 => 6.5.0
postcss-loader: ^6.2.0 => 6.2.0
style-loader: ^3.3.1 => 3.3.1
webpack: ^5.61.0 => 5.61.0
webpack-cli: ^4.9.1 => 4.9.1
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 20 (10 by maintainers)
I think I am in a bit of uncharted waters here with Hubspot. I think they will be quite responsive to this. As I think it will be easy to implement on their end.
As far as I know nobody that builds on the HubSpot platform is really using webpack for their projects because of how the platform is kind of built. But they are really pushing to get devs into their own ecosystem and I think that your solution here is likely the best.
I really wasnt thinking about how having invalid css would affect other tools such as linters and what not. So I think youre pointing me in the right direction.
Ill change my postcss syntax to auto format hubl expressions into comments. And then we should be good to go!
For sure - you know It looks like - they support this in an undocumented fashion. Those expressions still fire inside of a css comment block. They just arent removed server side.
I can change up my syntax a bit to accommodate for it in the mean time.
Appreciate your thoughts and help on this one!
Thanks I will look at this in near future 👍