-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Avoid unnecessary system-ui expansion #12522
Conversation
webpack.config.js
Outdated
features: { | ||
'system-ui-font-family': false, | ||
} | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can put this config into the postcss-loader
options. That way, it'll be easier to convert this file to ESM syntax later. Keep note that there are two such sections, one for CSS and one for Less.
{
loader: 'postcss-loader',
options: {
sourceMap: true,
plugins: () => [
PostCSSPresetEnv({
features: {
'system-ui-font-family': false,
},
}),
],
},
},
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was about to do this:
const PostCSSPresetEnv = (args) => {
args = {...args};
return require('postcss-preset-env')({...args,
features: {...args.features,
'system-ui-font-family': false,
}
});
};
I'm not sure about the link between ESM syntax and having this at two places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With ESM one would convert
const PostCSSPresetEnv = require('postcss-preset-env');
to
import PostCSSPresetEnv from 'postcss-preset-env';
meaning the import statement has to stand alone, so I think it's better to leave it a simple require
statement. You can optionally define the config on the top-level scope in a variable and reference that further down, but I don't see the duplication a big issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, didn't know that trick. The only thing that worries me a bit is that esm
seems to lean a bit on the unmaintained side, but I guess we can eventually remove this workaround once webpack supports node's ESM implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change looks good besides this. Can you either replicate the postCSSPlugins
variable usage in this PR or alternatively also merge the ESM conversion into here?
Codecov Report
@@ Coverage Diff @@
## master #12522 +/- ##
==========================================
- Coverage 43.44% 43.42% -0.02%
==========================================
Files 645 645
Lines 71328 71328
==========================================
- Hits 30986 30977 -9
- Misses 35331 35336 +5
- Partials 5011 5015 +4
Continue to review full report at Codecov.
|
I think you can use Oh, and please run |
"babel": {
"presets": [
"@babel/preset-env"
]
}
|
65b2b37
to
92bf4e7
Compare
Strangely enough, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I think it may be better to move the babel config to a .babelrc.json
so we only define it in one place for the whole project. Will test this later, blocking for now.
I was not able to get |
Built on latest MSYS2 with packaged Go and official Node.js 14.8.0. |
It was giving me BTW: I never requested this PR to do the ESM conversion so if you like, you can turn the imports back into |
How is Gitea officially built on Windows? By cross compilation or natively? I really don't think Cygwin is the source of the problem. Sounds more like path misconfiguration with Node.js. And I really think MSYS2 is just wonderful, aside from the not-so-great shell GUI (giving me broken encoding) which is replaced by the also wonderful Windows Terminal here. CI integration is also possible (though I don't see any benefit from that apart from ensuring the build setup works for those who are willing to build on Windows). |
Official binaries are cross-compiled. It should theoretically be possible to build on Windows natively when
I tried the webpack command in |
Found the issue. It's babel/babel#10232 (comment). My parent folder is a junction and it works after doing it in the actual destination directory. I don't think such workaround are acceptable, it's certainly a bug in the module. |
In this case, I believe it's commonplace to chain/call or even do whatever it's appropriate to the actual I'm actually testing swc-loader and @swc/register as a drop-in replacement to Babel. It now supports ES2020 which is pretty nice. |
Plain Node.js will always be fastest so I prefer to use that until we can use native module syntax.
I guess I don't really care. I've been personally avoiding doing anything directly on the same line as |
Oh, and here's the usage of swc in case it becomes suitable in the future: 5c913da
No, I'm actually replacing the webpack part, which becomes slower due to source map generation. The improvement in compilation time of In the context of Node.js, the other modules with Babel dependencies are actually what may benefit from the performance boost (they claim >= 18x) from swc. That's of course way beyond our scope, though. |
Faster transpilation is always welcome. I assume we soon won't need to transpile to ES5 (which last I checked is still happening) and can target more modern browsers which should reduce JS bundle size a bit (I've read it's around 30% less with ES5 polyfills gone). |
Offtopic: I'm certainly watching swc but for use in gitea, we'd need to adjust the release process and stop publishing |
Sounds like you're a lot more knowledgeable about fonts than I am. I'm happy if you want to atttempt to resolve #11045 in another PR later. Getting one globally working font stack sure is not a easy task. Gitee is probably biased towards Chinese audiences, GitHub towards western. |
Would you mind pulling in silverwind@41abd41 here? I feel like this is more readable as the config block in the middle of the requires looks odd to me. |
I got |
This should be enough:
Also, I strongly recommend not using |
The thing is, I actually wanted to merge my two commits to they are at one place in the history. I guess I'll just clone the whole thing again... |
|
I think that'll squash it onto its parent. That's bad. |
Ohh now I see what happened here... by merging your commit I resurrected those buried commits since you forked that branch from me... |
Would probably have been easier to use GitHub's "secret" |
Wow, as a relatively experienced Homebrew contributor I thought I'm fairly familiar with the existence of |
@@ -18,7 +18,7 @@ | |||
url('../fonts/noto-color-emoji/NotoColorEmoji.ttf') format('truetype'); | |||
} | |||
|
|||
@default-fonts: -apple-system, BlinkMacSystemFont, system-ui, 'Segoe UI', Roboto, Helvetica, Arial, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji" sans-serif; | |||
@default-fonts: -apple-system, BlinkMacSystemFont, system-ui, 'Segoe UI', Roboto, Helvetica, Arial, "Apple Color Emoji", "Segoe UI Emoji", "Noto Color Emoji", "Twemoji Mozilla"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just noticed it: Is the removal of Segoe UI Symbol
intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I take it as something in the same league as JIS fonts and DejaVu Sans. As I said earlier, it's not a major goal to cater users with need of these black-and-white icons (except for code, but maybe even there as well). I'm removing it to align the UX of legacy Windows to legacy Linux, where DejaVu Sans is only matched by sans-serif
. Testing it on Windows 7 shows the same effect with Segoe UI Symbol being matched by sans-serif
, so at least there won't be tofus.
There have been discussions regarding this in the past when browsers switched to prioritize emojis, a behavior originated on mobile platforms, cf. https://bugzilla.mozilla.org/show_bug.cgi?id=1054780.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another (positive?) side effect of this would be that Japanese users would see more native glyphs of dingbat symbols if they have compatible fonts in the :lang(ja)
stack installed. emoticons, people, objects and stuff will be unaffected. If I recall correctly, many JIS symbol designs from non-Japanese fonts (e. g. emoji fonts) look poor and broken. I haven't investigated the Segoe ones though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. Agree that plain color glyphs should not be used if better versions are available.
Had to force-push again to recover this lost change during the rebase: Line 82 in 8688513
|
Still looking good. I think the semicolons inside the parents can be removed but I see they were partially there before this PR so it's fine either way. |
That's what I tried before submitting this PR. Syntax error. |
cf. #11818 regarding emojis.