fix: ensure that alias
config gets passed through to the bundler when using new --x-dev-env
#6903
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.
What this PR solves / how to test
While this does fix the problem (it's a one-liner) and I added a test to prevent a regression,
we have a systemic problem here because the types are too loose within the
ConfigController
.One approach to fixing this is: rather than defining the
StartDevWorkerInput
, where all the props are optional, and then inferring theStartDevWorkerOptions
, we should flip it round. Make theStartDevWorkerOptions
tight (i.e. nothing can be optional, but explicitly can beundefined
if needed). And then infer theStartDevWorkerInput
from there by "picking" the desired properties and marking the type asPartial<>
.This would have created a typings error when the
alias
property was added to the config, and therefore indicate to the developer that it needs to be addressed here.There may be a better solution, perhaps using
zod
or similar. So I didn't do any refactoring in this PR to keep the fix simple to review and land.Alternatively, we could avoid manually copying over properties and rely upon a more automatic merging helper function that would mean the developer has to do nothing here when adding to the config.
(I believe that there was some discussion about how this config copying was awkward at the time, and I think the plan was to clean it up once the "other" way of doing dev was removed, which is not far off now. So perhaps this can all be done in one go?)
Moreover the test coverage of this code is pretty thin, so whether (or how) we fix the typings we should make the ConfigController tests much more comprehensive.
Fixes #6898
Author has addressed the following