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
feat(vite-node): options via CLI (fixes #1208) #1215
feat(vite-node): options via CLI (fixes #1208) #1215
Conversation
✅ Deploy Preview for vitest-dev ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
packages/vite-node/src/cli.ts
Outdated
deps: { | ||
inline: Array.isArray(inlineDeps) ? inlineDeps : [inlineDeps], | ||
}, |
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.
Should we also port the rest of the relevant configuration as CLI flags? Or would you rather keep the bare minimum, and add stuff when needed?
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 think we should at least port fallbackCJS
(with no-
prefix for false
) - I think minimist
provides this functionality out of the box, but I am not sure.
Also, what about regexp?
packages/vite-node/src/cli.ts
Outdated
deps: { | ||
inline: Array.isArray(inlineDeps) ? inlineDeps : [inlineDeps], | ||
}, |
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 think we should at least port fallbackCJS
(with no-
prefix for false
) - I think minimist
provides this functionality out of the box, but I am not sure.
Also, what about regexp?
I don't think we explicitly tested vite-node 🤔 One of the reason is because
Not all are relevant there, but maybe we can provide the ones that are not used in |
Maybe we could introduce a field like For CLI options, I am imagining something more automated, like |
Oh yes, good point. I'll try to look into it.
I'm still trying to get a feeling of how it could work from a consumer perspective, especially how we could avoid duplicating the configuration between Side notes:
|
@antoinerey I think ViteNode right now uses |
I'll definitely take a look at that! Thanks for the tip. |
Here is the first PR to replace minimist with cac. #1249 |
73770d7
to
f1e8323
Compare
packages/vite-node/src/cli.ts
Outdated
@@ -24,6 +28,7 @@ export interface CliOptions { | |||
root?: string | |||
config?: string | |||
watch?: boolean | |||
serverOptions?: ViteNodeServerOptions |
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.
Since the option is provided by the consumer, it might not match ViteNodeServerOptions
, so I'm cheating a little bit here.
However, we could rely on a TS guard to assert that the given options match the TS interface, but it would mean hardcoding the checks, and thus duplicating the source of truth between ViteNodeServerOptions
and the TS guard. Concretely, both could be out of sync, leading to issues.
Do you see another way to achieve this without duplicating the source of truth? 🤔
packages/vite-node/src/cli.ts
Outdated
// TODO: How could we document this? Ideally, we should link to the | ||
// TODO: ViteNodeServerOptions type since it's the source of truth. | ||
.option('--server-options <options>', 'Use specified Vite server options') |
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 could not find any proper example of such documentation. Should I add a few lines to the README?
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.
Yeah I think that would do
packages/vite-node/src/cli.ts
Outdated
}) | ||
} | ||
|
||
// TODO: Handle serverOptions.transformMode. |
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've noticed that serverOptions.transformMode.ssr
(and .web
) only accept Regexes, while serverOptions.deps.inline
(and .external
) accepts both strings and Regexes.
- Is that expected?
- If so, would you mind giving a bit of context as why? 🙏
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.
doesn't have a reason 👀
I guess just didn't notice. but to be honest I prefer using regexp always, because current solution for deps.inline
as a string is not reliable on non-npm/pnpm package managers
Converted the PR to draft since it's still WIP, and should probably not be merged. @sheremet-va @antfu I've pushed a new version of this PR using vite-node --server-options.deps.inline="module-1" --server-options.deps.external="module-2" script.ts Before going further (adding tests, polishing the code, etc.) I would like to get feedbacks, especially about ideas discussed in comments. Do you feel like this is going into the right direction? 🙏 |
@sheremet-va Friendly ping. 🤗 Do you feel like a TS guard could be a nice solution even though it duplicates the shape of the options? Or should we keep a single source of truth instead? |
I think the whole idea why we are doing this is to just do it and forget kind of situations. |
3d9d2b3
to
2a96ef8
Compare
I guess we're good now. 🤗
|
Renamed to |
Fixes #1208
This PR adds a new flag to the
vite-node
CLI:--server-options
. Using dot syntax, it's now possible to define any option passed to the underlying ViteNodeServer instance.Because CLIs do not support RegExp as input, we make sure to transform any string that looks like
/xxx/
to RegExps.