feat(cli): enforce vite-plus import lint rule#1408
feat(cli): enforce vite-plus import lint rule#1408Han5991 wants to merge 29 commits intovoidzero-dev:mainfrom
Conversation
✅ Deploy Preview for viteplus-preview canceled.
|
1fe3184 to
3a43e6d
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7eceea6afe
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Awesome, the import rewrite logic can be completely replaced with the oxlint plugin. |
Makes sense. I focused this PR on the unsafe rewrite fix first, and I can move the remaining import rewrite logic into the oxlint plugin in a follow-up. |
camc314
left a comment
There was a problem hiding this comment.
This looks good! but we should definitely use oxlint's types rather than handrolling it, it duplicates code, and might cause issues in future!
b757aaf to
57897c7
Compare
|
The failure appears to come from a version skew in the global snap test. In this test, The local CLI generates a lint config that references That means oxlint sees the registry-installed This also explains why the other |
|
I think there are three possible ways to address this.
The failure is caused by mixing the locally built CLI under test with This avoids the version skew and keeps the test focused on the current build. A packed tarball seems better than
Another option is to make That would keep the generated app’s registry-installed dependencies intact, but it changes production resolution behavior. I would be careful with this because it may be harder to justify unless built-in Vite+ plugins are explicitly meant to be provided by the running CLI rather than by the project’s installed
We could also leave the test behavior as-is and consider the failure expected until the package containing This is the most conservative option, but it means the global snap test can fail whenever the local CLI starts generating config that depends on an unreleased |
7930f65 to
7ab5df7
Compare
359fd37 to
273e4fb
Compare
| return fs.readFileSync(a).equals(fs.readFileSync(b)); | ||
| } | ||
|
|
||
| function assertGlobalCliBinaryMatchesCheckout(binDir: string, casesDir: string): void { |
There was a problem hiding this comment.
@Han5991 Can we create a new GitHub Action to test the oxlint plugin logic? This way we won't need to test through snap test. Currently, because we have to test through snap test, the modification logic for snap test has become too complex.
There was a problem hiding this comment.
Yes, I think we can add a dedicated GitHub Action/job for the oxlint plugin integration test. That should be a better place to verify that oxlint can load vite-plus/oxlint-plugin through package exports and that the rule/fix works, instead of relying on snap-test output.
One note: the snap-test changes here were added because the current global snap-test environment can still execute against the previously installed global vite-plus package. In that setup, even if this PR adds the ./oxlint-plugin export, oxlint may resolve vite-plus/oxlint-plugin from the stale installed package instead of the checkout and fail to find the plugin. That is why I forced the global CLI JS entry and relinked installed checkout packages.
I can split this so the oxlint plugin behavior is covered by a focused CI job, and keep only the minimal snap-test fix needed to ensure global snapshots run against the current checkout.
� Conflicts: � pnpm-lock.yaml
d38d6fc to
b6ef1e7
Compare
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Summary
vite/vitestimports tovite-pluslintconfigTesting
command-init-inline-configandlint-vite-plus-importsCloses #1301
Closes #1457