There's room for improvement still. Currently, the production build is using long-dev class names. e.g. `DirectoryContent-module__Box_3__gl6dE` could be compiled to a shorter hash like `gl6DE3a2`.

If you use Vite:

  css: {
    modules: {
      generateScopedName: mode === 'production'
        ? '[hash:base64:8]'
        : '[name]__[local]___[hash:base64:5]',
      }
    }

▲ eviks 2 hours ago | parent | next [-]

The improvement would be shipping human-readable structure to allow easier user overrides, not that hash abomination

▲ robin_reala 2 hours ago | parent | prev | next [-]

Those class names surely gzip better than hashes over the wire?

	▲	efortis an hour ago \| parent \| next [-]
		Here's a comparison using `brotli --best` on my app. `53K _long.css 38K _short.css 11K _long.css.br 8.9K _short.css.br` Both, dev and prod, have hashes because that's part of what CSS Modules uses to avoid collisions. Besides download size, smaller names improve parsing speed too.
	▲	notpushkin an hour ago \| parent \| prev [-]
		This. The only thing hashing classes achieves is making it difficult for users to use ad blockers and/or custom CSS. I understand why e.g. Meta does it on their sites, but for GitHub it makes no sense.

▲ Onavo 2 hours ago | parent | prev [-]

Would you need a source map then for prod debugging?