-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
kit: implement server components dev server #14025
Conversation
921cec6
to
a0956f2
Compare
you can use --server-components with bun build, and you get a slightly more correct output. this output is not yet perfect or usable. but i am committing this as a checkpoint as the next step is a large design change for how `kit.DevServer` bundles and re-bundles files we are removing the old `Framework` struct, and replacing it with a new one with a similar purpose: configuration options targeted towards framework developers. it tells the bundler how to glue the framework to the application, mostly in regards to react server components introduce `bundle_v2.AstBuilder`, which is used for parallel generation of virtual modules. previously, this used a string builder combined with the javascript parser. this is silly and will not be fun to use for the 3-5 file kinds that the bundler will have to generate. this builder makes it very easy introduce `kit.DevServer.IncrementalGraph`, which will keep track of changes between bundle tasks. however, this code is not ripe and will be iterated on extensively. i don't think it's approach is sound yet
there are two `IncrementalGraph`s. one for the client and one for the server. the plan is all routes share these two graphs, de-duplicating cross-route work. more explanation is left in documentation comments. more server components bugs are fixed, but not all. it is in a weird state where some files are tree-shaken away, as well as bogus output like `const Client = Client;`
a0956f2
to
2de1a7a
Compare
@@ -3027,8 +3299,10 @@ pub const ParseTask = struct { | |||
opts.features.emit_decorator_metadata = bundler.options.emit_decorator_metadata; | |||
opts.features.unwrap_commonjs_packages = bundler.options.unwrap_commonjs_packages; | |||
opts.features.hot_module_reloading = bundler.options.output_format == .internal_kit_dev and !source.index.isRuntime(); | |||
opts.features.react_fast_refresh = (bundler.options.hot_module_reloading or bundler.options.react_fast_refresh) and | |||
loader.isJSX() and !source.path.isNodeModule(); | |||
opts.features.react_fast_refresh = target == .browser and |
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.
only browser?
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.
Yes. there is no mounted DOM to live-patch on the server.
@@ -2039,7 +2033,9 @@ fn NewPrinter( | |||
p.print(".require("); | |||
{ | |||
const path = input_files[record.source_index.get()].path; | |||
p.printInlinedEnum(.{ .number = @floatFromInt(path.hashForKit()) }, path.pretty, level); | |||
p.print('"'); |
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.
what's the story here?
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.
using numbers for module specifiers is going to be too much of a debugging burden on myself and framework developers. it isn't worth the unproven performance boost this idea had, especially considering the two other bundlers on my mind see decent performance with strings (and their string contents are much more verbose).
if E.String is too big then that should be optimized
// TODO: is a higher upper bound required on Windows? | ||
// Alternate solution: calculate the upper bound by summing | ||
// framework paths and then reusing that allocation. | ||
var end_buf: [65536]u8 = undefined; |
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.
lol
bun