feat(v2): introduce new minification of CSS bundle#3716
Conversation
| serverConfig.output && | ||
| serverConfig.output.filename && | ||
| typeof serverConfig.output.filename === 'string' | ||
| serverConfig?.output && |
There was a problem hiding this comment.
I don't know why, but TypeScript was throwing a bunch of errors related to this piece of code, so I had to use optional chaining to get rid of them.
There was a problem hiding this comment.
this is surprising, do you remember the TS error?
There was a problem hiding this comment.
tried to remove these typing changes and the package build was successful this time. Strange, so reverted these changes.
|
|
||
| export default function createServerConfig({ | ||
| props, | ||
| minify = true, |
There was a problem hiding this comment.
Since we are not doing any optimizations in the server config I removed the minify option so as not to be misleading (instead this, the default values for minify-related options are defined in the base config function)
|
Deploy preview for docusaurus-2 ready! Built with commit e5a3312 |
There was a problem hiding this comment.
- 1 for better minification
Was wondering if purgecss couldn't be used for this usecase instead of custom postcss logic?
Also do we want to keep the 2 modification modes over time, or is it temporary? If we want to keep it, I don't really like the name of this option, and using boolean means we can't introduce easily a 3rd option in the future
I'd rather avoid having fn args list grow, a single option object is more suitable for long term maintenance.
Note: this is likely to conflict with my i18n branch, so try to avoid refactoring too much the build/start commands in general, until i18n is merged (https://github.com/facebook/docusaurus/pull/3325/files), as I still plan to modify these files.
| serverConfig.output && | ||
| serverConfig.output.filename && | ||
| typeof serverConfig.output.filename === 'string' | ||
| serverConfig?.output && |
There was a problem hiding this comment.
this is surprising, do you remember the TS error?
| | `--bundle-analyzer` | `false` | Analyze your bundle with the [webpack bundle analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer). | | ||
| | `--out-dir` | `build` | The full path for the new output directory, relative to the current workspace. | | ||
| | `--no-minify` | `false` | Build website without minimizing JS/CSS bundles. | | ||
| | `--use-old-css-minifier` | `false` | Use only default preset cssnano for CSS minification (see info below for more details). | |
There was a problem hiding this comment.
if we want to keep this over time, and maybe later change or add new minifier logic, what about giving a proper name to each config? like "simple" vs "advanced" or something?
boolean + the "old" term do not look very extensible to me
|
@slorber I replaced the option with environment variable to minify CSS code in the simple way (as was earlier), so PR description and docs are actualized. |
3 participants
Motivation
Since we are not using tree-shaking for CSS, it is very important for us to keep final CSS bundle size as small as possible. In this PR I am using additional tools to optimize/minify the CSS bundle as best as possible:
--ifm-primary-color(remove-overridden-custom-properties)Since this is a pretty big/deep/hard/"aggressive" minification, there is a chance of broken CSS, although it shouldn't be in normal usage. In general, to mitigate this, I also added the option for the build script (
--use-old-css-minifer), which will use the old CSS minification mechanism.But again, although there is a risk of broken CSS as a result of new minification, this should not happen in normal use cases of Docusaurus. Perhaps in more complex cases, when users may have a lot of custom CSS code, then the new minification may break something in final CSS, but it is possible that due to incorrect use of CSS. I propose to deal with such problems in a separate order to improve the new CSS minifier, which would be suitable for all our users (see new docs in cli.md).
Apart from that, I did some cleaning of the CSS styles:
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Benchmarks:
Before this PR:
DISABLE_VERSIONING=true yarn build=> styles.css size is 99.2 kB (current)After this PR:
DISABLE_VERSIONING=true yarn build USE_SIMPLE_CSS_MINIFIER=true=> styles.css size is 98.3 kB (after CSS cleanup)DISABLE_VERSIONING=true yarn build=> styles.css size is 84.4 kB (preview)Saved 14.8 kB or 14.9%!
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/facebook/docusaurus, and link to your PR here.)