Build Tooling: Explore faster builds split into individual packages #37318
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
youknowriad
requested review from
gziolo,
jsnajdr,
nerrad,
Mamaduka,
mcsf and
mtias
youknowriad
added
the
[Type] Technical Prototype
|
Size Change: +6.59 kB (+1%) Total Size: 1.11 MB
ℹ️ View Unchanged
|
gziolo
changed the title
Closed
jsnajdr
reviewed
Dec 13, 2021
There was a problem hiding this comment.
The swc migration is surprisingly straightforward! It helps that Gutenberg doesn't use any custom plugins. Except @emotion/babel-plugin which optimizes the css syntax. That will need to be addressed somehow.
I liked the centralized bin/packages/build.js script. I don't see much upside to copying the same stuff over and over in each of the package.jsons.
| @@ -28,11 +28,25 @@ | |||
| "react-native": "src/index", | |||
| "types": "build-types", | |||
| "dependencies": { | |||
| "@babel/runtime": "^7.16.0", | |||
There was a problem hiding this comment.
The @babel/runtime will need to be replaced by @swc/helpers and the jsc.externalHelpers = true config option. Otherwise all the helpers (for more complex transpilations like classes, async, iterators, ...) would be duplicated in each compiled file.
There was a problem hiding this comment.
yeah, I saw that, I wanted to check how much of a bundle size impact it would have to avoid the helpers.
|
@youknowriad Does this patch already compile JSX to To make it work with SWC, we'll probably need to move to the new SWC lets you specify the With |
|
@jsnajdr it doesn't compile JSX yet, and the reason is mentioned on the description. (you're right about move to automatic but it's not that simple) |
This is on the Next.js roadmap as noted in https://nextjs.org/blog/next-12:
While this would work great for the Gutenberg plugin, it is suboptimal for npm packages published to npm. As far as I'm aware, libraries still ship code that uses direct access to |
|
There is also an open discussion started by @kevin940726 in #36142 about the general improvements to the build development workflow where we could summarize all the findings from this PR and from the efforts to start using |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to #36142.
This is not necessarily meant to land as is but more an exploration to see what's possible in the future.
My main motivation here was that the JS community has been evolving in the last couple years, there are new approaches, new toolings... and I wanted to see how other folks approach monorepos what makes sense for us to adopt. Some of the tools I've looked at:
Some of my own conclusions/notes:
Initial exploration in this PR:
In this particular PR, I trying seeing whether we can use one of the two most popular Rust/go based JS compilers instead of babel for our packages (swc or esbuild, I've tried both and used swc for now).
The first take away for me is that we could benefit from having each package define its own "build" command instead of handling this top-level, there are a couple advantages for this:
The other take away for me is related to the adoption of these rust/go builders and the removal of babel: We have too many babel specific logic in our chains that we should try to eliminate over time if we want to avoid the lock-in to last forever while the JS community abandons babel.
jsx-runtimeentry for the new automatic JSX transform #34221 (comment)Curious what you think about my ramblings and also the current PR (package specific builds, swc...)