layershifter
commented
1 year ago The problem with types affects also consumer side. In the project we have the whole set of icons bundled:
import {
bundleIcon,
AccessTimeFilled,
AccessibilityFilled
} from "@fluentui/react-icons";
export const AccessTime: FluentIcon = /*#__PURE__*/ bundleIcon(
AccessTimeFilled,
AccessTimeRegular
);
/* all other icons */
/* ... */The problem what we have is build performance: we use TS compiler to compile TS code and generate type definitions. tsc --extendedDiagnostics gives following:
✖ Files: 755
✖ Lines of Library: 32995
✖ Lines of Definitions: 384954
✖ Lines of TypeScript: 12437
✖ Lines of JavaScript: 0
✖ Lines of JSON: 0
✖ Lines of Other: 0
✖ Nodes of Library: 149996
✖ Nodes of Definitions: 1566104
✖ Nodes of TypeScript: 31750
✖ Nodes of JavaScript: 0
✖ Nodes of JSON: 0
✖ Nodes of Other: 0
✖ Identifiers: 509267
✖ Symbols: 1071185
✖ Types: 31575
✖ Instantiations: 3317977
✖ Memory used: 928504K
✖ Assignability cache size: 41352
✖ Identity cache size: 309
✖ Subtype cache size: 430
✖ Strict subtype cache size: 0
✖ I/O Read time: 0.30s
✖ Parse time: 1.21s
✖ ResolveModule time: 0.19s
✖ ResolveTypeReference time: 0.07s
✖ Program time: 1.84s
✖ Bind time: 0.53s
✖ Check time: 6.67s
✖ printTime time: 65.60s
✖ Emit time: 65.60s
✖ transformTime time: 65.31s
✖ Source Map time: 0.01s
✖ commentTime time: 0.03s
✖ I/O Write time: 0.05s
✖ Total time: 74.64sTime printTime, Emit time & transformTime are insane 💥
Running with emitDeclarationOnly if printTime is high. https://github.com/microsoft/TypeScript/wiki/Performance#performance-considerations
I run the same build with declaration: false (which we can't really do):
✖ Check time: 7.33s
✖ printTime time: 0.30s
✖ Emit time: 0.31s
✖ transformTime time: 0.04s
✖ Total time: 12.18sAt the same time I tried to collect CPU profile to understand what explodes:
Current state
declaration: false
getAccessibleSymbolChainFromSymbolTable points to https://github.com/microsoft/TypeScript/issues/34119 where the similar issue is discussed: performance slowdown on huge types. Considering that I tried to simplify types to avoid complex d.ts like this:
Basically did explicit typing to FluentIcon:
+import * as React from "react";
+type FluentIcon = React.FC<
+ React.SVGAttributes<SVGElement> & {
+ primaryFill?: string | undefined;
+ className?: string | undefined;
+ filled?: boolean | undefined;
+ title?: string | undefined;
+ }
+>;
-export const AccessTime = /*#__PURE__*/ bundleIcon(
+export const AccessTime: FluentIcon = /*#__PURE__*/ bundleIcon(
AccessTimeFilled,
AccessTimeRegular
);The change results in:
✖ printTime time: 0.30s
✖ Emit time: 0.31s
✖ transformTime time: 0.10s
✖ Source Map time: 0.01s
✖ commentTime time: 0.02s
✖ I/O Write time: 0.03s
✖ Total time: 8.49sI am not sure if better typings for icons on lib side will change things, but it would be great to test.
spmonahan
kkocdko
MLoughry
svdoever
carmezini
lainRosensteel
thelok
Hotell
Library
React Components / v9 (@fluentui/react-components) & @fluentui/react-icons.
Current state with tooling
Webpack
In development
To be done
In production
Tree-shaking works ✅ Bundles reasonably fast (webpack 5.75.0 on Apple M1 in 1857 ms, 2048 ms) ✅
CodeSandbox
non cloud
Works surprisingly well (even with 4x CPU slowdown): https://codesandbox.io/s/naughty-paper-14wujx?file=/src/App.js
Uses CJS and loads all chunks for every icon ⚠️
cloud beta
Works even better https://codesandbox.io/p/sandbox/priceless-knuth-m8e6iz
Loads bundled ESM by Vite (around 2.1mb)
TypeScript
Used TS 4.9.4. Builds a fixture reasonably fast with
skipLibCheck: true&skipLibCheck: false✅Next.js
Used Next.js 13.0.6. Rebuilds in dev are reasonably fast. Builds, too (on Apple M1 12.37s with icons, 8.67s without).
create-react-app
In development
To be done
In production
It's still Webpack under hood, but they process
node_moduleswith Babel loader 💥build17.07s with iconsbuild3.30s without iconsbuild4.51s with iconsbuild3.33s without iconsJest
Does not seem that icons affect it in any way.
Package size
It's where things are getting worse. react-icons-2.0.190.tgz downloadable size is 15.1mb, unpacked size is 71mb 💥
Fonts
It's a big problem actually as it double package twice.
Action 1 (mandatory): glyphs should be present once
Currently glyphs are present twice for CJS & ESM 💣 However, fonts are not modules and a JSON file next them is also not a module.
https://www.jsdelivr.com/package/npm/@fluentui/react-icons?path=lib%2Futils%2Ffonts https://www.jsdelivr.com/package/npm/@fluentui/react-icons?path=lib-cjs%2Futils%2Ffonts
If we will have a single instance we go down to 63mb (-8mb!) unpacked.
Action 2: remove fonts completely
Move fonts and related JS to a separate package:
While the plugin looks on a relative path - I don't think that it's a good enough reason to keep ghyphs and slow down installs for everyone.
Deleting fonts completely moves us down to 41mb.
Types
Duplicate types
Currently we have separate types for ESM and CJS:
It means that we duplicate definitions for a no reason as the
package.jsonreferences onlylib/index.d.tsand we have export maps that prevent deep imports.Duplicate types cost 5mb. Ideally, it would be great to rollup them.
Expanded definitions ✅
We have this for every icon, types are inlined, not great at all.
Killing a generic there makes types more accurate:
Ideally, it should be just:
Usage of a type without
displayNameprobably will lead to better results. Just the change above saves 3mb.Minify output
To be done.
Requested priority
High