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.
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
[Miniflare 3] Add support for routing to multiple Workers #520
[Miniflare 3] Add support for routing to multiple Workers #520
Changes from 1 commit
9229b30
839b02c
f095aad
4e99a58
1abbdbc
b7e619e
0e2c68d
0ed3049
a629360
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
The
// @ts-expect-error
s appear to be becausePluginSharedOptions
hasreadonly
keys, which can be fixed (and the errors removed) by removing theas const
inpackages/tre/src/plugins/index.ts
. Would it be possible to make that change, or would it break something else? If it's not possible, could the// @ts-expect-error
comments be updated?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.
Hmmm, I think removing the
as const
should be ok. It looks like that still keeps the specific Zod types so options inference/completions still work. Will make that change. 👍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.
839b02c (unfortunately the change to enforce code means
CoreOptionsSchema
has required options that aren't satisfied by the other options types, so we still need some// @ts-expect-errors
)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.
This should probably have specific handling for multiple unnamed workers, since this error message won't be very helpful with an empty string
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.
1abbdbc
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.
If there are multiple unnamed workers, will this overwrite some routes?
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 wonder if worker names should be required
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.
It would, but we've validate names are unique beforehand. Perhaps an assertion that
allRoutes
doesn't contain the key would be a good idea?In the single worker case, I don't think they should be. I do agree with you later on though that some of the error messages should be better in this case.
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.
f095aad
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.
serviceNames
seems to just be used for de-duplication of services. What about makingservices
aMap<string, Service>
, getting rid ofserviceNames
, and then returningservices.values()
? It feels likeserviceNames
andservices
could easily get out of sync as this code evolves (if another services source other than just global/plugiin specific is added, it seems like it would be easy to forgot to add the necessary additional de-duping code)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.
That's a much better idea 😃 , will make that switch 👍
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.
b7e619e
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.
In the spirit of extracting shared options, the compatibility date could probably also be extracted
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.
0e2c68d
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.
Why the move of
CORE_PLUGIN_NAME
out ofcore
?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.
This was so we could use it in
SERVICE_LOOPBACK
without a cyclic dependency oncore
:miniflare/packages/tre/src/plugins/shared/constants.ts
Line 10 in 9229b30
Though I think moving global services to shared makes a lot more sense. Then we could just rename this
loopback
or something.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.
4e99a58
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.
Why can any workers have no code? What does it mean for a worker to not have code defined?
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.
Hmmm, I suppose that doesn't really make sense, since we don't expose
workered
's other service types (disk, network, etc) outside ofserviceBindings
. Will make code required for all Workers. 👍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.
839b02c
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.
This feels like it probably shouldn't be in the
core
plugin?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.
Hmmm, maybe. That might help with the moving
CORE_PLUGIN_NAME
issue you raised later on too. Will move it out intoplugins/shared/services.ts
or something. 👍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.
4e99a58