index.css does not match index.css.map #12325
Comments
|
I can only imagine this being a bug in either cssnano-webpack-plugin or cssnano. The former was switched from optimize-css-assets-webpack-plugin specifically because of better source map support. |
|
I’ve just tested and it appeared already in #9983. It’s not the fact that the source map was any wrong, but rather correct whereas the actual CSS is faulty. Can’t imagine how that could happen since the translator is the same, isn’t it? And if cssnano were to blame, how come it didn’t happen earlier (the commit right before that PR was alright FYI)? |
|
Can you try with |
|
I wasn’t actually talking about the result, but the actual files generated in the build directory. The resulting static file was already different after #9983. Now the fact a CSS file mismatches the source map is another weird thing. But if you mean serviceworker would generate something else that shadows Edit: added the setting. Effective rules do not change (as expected). And double-checked the static files are freshly generated each time. Edit 2: something very curious happened when I do with - @default-fonts: -apple-system, BlinkMacSystemFont, system-ui, 'Segoe UI', Roboto, Helvetica, Arial;
+ @default-fonts: BlinkMacSystemFont, system-ui, 'Segoe UI', Roboto, Helvetica, Arial;NB: this is all tested with detached HEAD at |
|
I did a quick Any chance they could do anything strange here? I believe none of the above actually comes from #9983. |
No, that's not possible. I was just thinking maybe it was serving a cached asset before your change but I'm pretty sure cache invalidation is working correctly for it and |
|
I think it's more likely you've hit some bug in the Less source map generation. I want to move off Less variables to CSS variables for the fonts (#11045) which may fix that situation. |
|
Is this still an issue? We've now switched to the new css-minimizer-webpack-plugin and I personally have not noticed any issue with its sourcemaps. |
|
I'll take a look. Running this on my own web server takes almost forever (screenshot from the version referred to in this issue, just fired up), but I don't want to test it locally... |
|
200s template emission time? Something is definitely wrong there, nevery seen anything like it. |
No, 28.4s (but still remarkable). This is mainly due to some SSD configuration of my VPS I believe. CPU is constantly at 100% upon starting gitea for around 3 minutes... |
|
Yeah, compared to Gogs on the same server, Gitea is at least 50% slower. I'm limiting the resources using cgroups, though. Have seen too many occasions where things get OOM-killed, and that single-core CPU is very precious for the handful of services I keep there (JVM and Node.js are both famous resource hoggers). |
|
No dice. Still the same thing. As long as this mixin is used as it is right now, it would always go in that way. I still suspect the problem happens in webpack less compiler itself somehow. I don't know the lifecycle, though. |
|
Can this be reproduced on https://try.gitea.io? For example if I view the font definitions in Chrome:
Clicking the line number seems to correctly show the Less source:
|
|
You have just proven my point. The definition is: Yet the result is: Apart from the comma before |
|
Damn, I see where it comes from: |
|
Not sure if this is idiomatic but it's working now: diff --git a/webpack.config.js b/webpack.config.js
index d7f0c83d8..8a2f2dbc0 100644
--- a/webpack.config.js
+++ b/webpack.config.js
@@ -4,7 +4,11 @@ const CssMinimizerPlugin = require('css-minimizer-webpack-plugin');
const FixStyleOnlyEntriesPlugin = require('webpack-fix-style-only-entries');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const MonacoWebpackPlugin = require('monaco-editor-webpack-plugin');
-const PostCSSPresetEnv = require('postcss-preset-env');
+const PostCSSPresetEnv = () => require('postcss-preset-env')({
+ features: {
+ 'system-ui-font-family': false,
+ }
+});
const TerserPlugin = require('terser-webpack-plugin');
const VueLoaderPlugin = require('vue-loader/lib/plugin');
const {statSync} = require('fs'); |
|
Ah, I wasn't aware of that |
[x]):Description
This is related to #11997.
It might be my fault to have failed to understand how exactly the build system works, or even be a bug somewhere in the toolchain, but the content of
/public/css/index.cssdoes not match/public/css/index.css.map.This is tested multiple times, even after a complete rebuild using
git clean -xdf --exclude=node_modules/* .followed byTAGS="bindata" make build.In particular, I moved
sans-serifto the end of the font stacks in the function.override-fonts, which emerged in d78bb1d and worked fine up till 1.11.x. Going through both files shows that the function does not resolve into what it was before (compareindex.css.maporindex.cssfrom any version between 1.9.x and 1.11.x by searching for:langor so).Screenshots
(It does involve the web interface, but you could probably check https://mikeslab.dix.asia/gitea/CL-Jeremy/gitea/pulls/1).
The text was updated successfully, but these errors were encountered: