ref(build): Use sucrase for watch npm builds
#5059
Conversation
size-limit report 📦
|
lobsterkatie
force-pushed
the
kmclb-use-sucrase-for-watch-npm-builds
branch
2 times, most recently
from
30c2d1c to
6d7f34d
Compare
lobsterkatie
changed the title
watch npm buildswatch npm builds
There was a problem hiding this comment.
I don't understand why packages need to watch their dependants. In cjs/esm, packages should be able to be built independently from each other, meaning for example, a change in core will not influence the generated esm/cjs code in browser. Am I understanding this right? This feels redundant to me.
It won't change it, but it may force changes to it. Say |
lobsterkatie
force-pushed
the
kmclb-use-sucrase-for-watch-npm-builds
branch
from
6d7f34d to
a9507b1
Compare
Misusing imported functions shouldn't affect the building of a package. It affects the typing - we should definitely watch dependencies when running |
No, upon further thought, I think I may be the one who's conflating things. Compiling and typechecking have been so intertwined in my head for so long that I don't think I stopped to think just how much this change to sucrase divorces the two. I'll pull that part out (which makes things much easier, BTW!) and stash it in a branch in case this logic somehow doesn't hold (though I think you're right, I don't think we'll need it). Thanks for pushing back on this! |
lobsterkatie
force-pushed
the
kmclb-use-sucrase-for-watch-npm-builds
branch
from
a9507b1 to
b59a360
Compare
lobsterkatie
changed the title
watch npm buildswatch npm builds
This follows up on #5035, which switched our main build commands to use rollup and sucrase instead of tsc, and brings that same change to our `build:watch` commands. Note: Running either of these `watch` commands produces different feedback than the `tsc` watch commands we're used to, in that the `build:types` component auto-watches dependencies (and will trigger a cascading rebuild on change), but the `build:rollup` component doesn't (and therefore only rebuilds the changed package). The reason for this is that sucrase and rollup are truly only *trans*piling (IOW, smushing the code touching other packages around in a non-semantic way, only really worried about whether it's legal JS, not whether it plays the way it should with those other packages), not *com*piling (actually understanding the entire, cross-package AST and refusing to produce code if the interfaces between packages don't match up). The utility of `tsc`'s rebuild of dependent packages was never actually to change the built code of those packages, it was just that the rebuild attempt forced a cascading typecheck, so we could know what _we_ had to change in the dependent packages' code. The process building types still serves this function, but the process building code doesn't need to and therefore there's no need for the cascade. (As you'll see in the conversation below, I myself was fuzzy on this point at first, which is why I'm spelling it out here quite so explicitly, in case any future readers stumble into the same wrong assumptions I did.)
This follows up on #5035, which switched our main build commands to use rollup and sucrase instead of tsc, and brings that same change to our
build:watchcommands.Note: Running either of these
watchcommands produces different feedback than thetscwatch commands we're used to, in that thebuild:typescomponent auto-watches dependencies (and will trigger a cascading rebuild on change), but thebuild:rollupcomponent doesn't (and therefore only rebuilds the changed package). The reason for this is that sucrase and rollup are truly only transpiling (IOW, smushing the code touching other packages around in a non-semantic way, only really worried about whether it's legal JS, not whether it plays the way it should with those other packages), not compiling (actually understanding the entire, cross-package AST and refusing to produce code if the interfaces between packages don't match up). The utility oftsc's rebuild of dependent packages was never actually to change the built code of those packages, it was just that the rebuild attempt forced a cascading typecheck, so we could know what we had to change in the dependent packages' code. The process building types still serves this function, but the process building code doesn't need to and therefore there's no need for the cascade. (As you'll see in the conversation below, I myself was fuzzy on this point at first, which is why I'm spelling it out here quite so explicitly, in case any future readers stumble into the same wrong assumptions I did.)