-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
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
[docs] Reduce bundle size #16046
[docs] Reduce bundle size #16046
Conversation
Details of bundle changes.Comparing: a3ae056...5503947
|
Something is off with the typescript compilation. I now realized that this means we bundle them both and also run both. It's probably best to revert this change and stick with |
What do you mean by we run and bundle them both? |
Don't know how describe this otherwise. The JS and the transpiled TS is bundled and evaluated. The variant used switches when the codevariant switches. Neither of which is useful. The JS version is equivalent at runtime. |
As long as we can, in development, edit the TypeScript demos and see the changes live (without any additional script running), I'm happy. I'm worried that requiring a running script will make the demo edition experience slower. |
Just wading through babel, webpack and next configs now. We can think about this later. If it requires too much configuration I'll revert. Having another script running in the background shouldn't be a problem. Plenty of popular repos require this (i.e. when testing production bundles). |
It seems that we will have to make a tradeoff. Here are the important dimensions I can think of:
|
Not sure what's happening currently. If I entry on pages with complementary projects I get May very well be that our current dependency graph is not supported. Will try to get minimal example that highlights the graph and see when it breaks. Build is passing because production is still using the old config. |
3bb2e9f
to
fd3913c
Compare
I seem to be on the right track: $ yarn docs:dev
# visit localhost:3000
# navigate to pickers demo
# works
# but land directly on localhost:3000/components/pickers and files inside node_modules requiring `@material-ui/*` files can't find the those modules. |
fd3913c
to
a7b0756
Compare
eed9376
to
c60da1a
Compare
Probably need to be more granular about externals. Works locally but I doubt we can increase the memory limit in CI. |
Very high memory consumption when inlining @material-ui/ packages
db36461
to
93b0231
Compare
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.
:)
docs/babel.config.js
Outdated
['next/babel', { 'preset-env': { modules: 'commonjs' } }], | ||
'@zeit/next-typescript/babel', | ||
], | ||
presets: ['next/babel', '@zeit/next-typescript/babel'], |
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.
Would it be enough?
presets: ['next/babel', '@zeit/next-typescript/babel'], | |
presets: ['next/babel'], |
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 so. That should've been removed when upgrading to next 9
* [docs] Use ES6 modules for client builds * Use blocklist for externals instead of allowlist * Use babel for aliases Very high memory consumption when inlining @material-ui/ packages * Remove next-transpile-modules * poke codecov * poke codecov * Remove redundant @zeit/next-typescript/babel
Let
next
decide on the used module format.Replaces
next-transpile-modules
with a custom config.next-transpile-modules
(despite its name) is not concerned with transpiling node_modules but modules of a monorepo.Using
babel-plugin-module-resolver
to alias@material-ui
packages of this repository in 3rd party librarys (notistack, material-table etc). No need to apply all presets/plugins.Followup: