fix(compiler-sfc): simulate allowArbitraryExtensions on resolving type (fix #13295)
#13301
Conversation
WalkthroughThe changes introduce support for TypeScript's Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Resolver
participant FS
User->>Resolver: Import type from './Foo.vue'
Resolver->>FS: Check if './Foo.vue' exists
alt Unknown extension and allowArbitraryExtensions enabled
Resolver->>FS: Check if './Foo.d.vue.ts' exists
alt Declaration file exists
Resolver->>FS: Read './Foo.d.vue.ts'
Resolver->>Resolver: Parse type from declaration file
else Declaration file does not exist
Resolver->>FS: Read './Foo.vue'
Resolver->>Resolver: Parse type from original file
end
else Known extension
Resolver->>FS: Read './Foo.vue'
Resolver->>Resolver: Parse type from original file
end
Assessment against linked issues
Poem
Tip ⚡️ Faster reviews with caching
Enjoy the performance boost—your workflow just got faster. ✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/compiler-sfc/src/script/resolveType.ts (1)
1155-1168:allowArbitraryExtensionsimplementation – consider extra fallbacksGreat to see the stub lookup being implemented. A couple of edge-cases you may want to cover:
If the importee (e.g.
./foo.css) itself does not exist but./foo.d.css.tsdoes,resolveExt()will currently fail, because the resolution path never checks for.d.<ext>.ts.
Either extendresolveExt()(preferred) or add a quicktryResolve(arbitraryTypeSource)before giving up.The call to
resolveParserPlugins('ts', parserPlugins, true)forces the “declaration file” flag to
true, even though files likefoo.d.css.tsare not.d.tsin the classical sense. Passing the real declaration-ness, e.g./\.\d\.[cm]?ts$/.test(arbitraryTypeSource)keeps behaviour consistent with the existing
.d.tsbranch.Example tweak (inside
resolveExt, but shown here for context):- tryResolve(filename + `.tsx`) || + tryResolve(filename + `.tsx`) || + // allowArbitraryExtensions support + (/\.[^./]+$/.test(filename) && tryResolve(`${filename}.d${extname(filename)}.ts`)) || tryResolve(filename + `.d.ts`) ||This would let consumers omit the physical
.css/.svgfile when they only care about types.packages/compiler-sfc/__tests__/compileScript/resolveType.spec.ts (1)
1438-1459: Comprehensive test forallowArbitraryExtensionsadded – nice!The new test covers both
.vueand.cssarbitrary-extension stubs and fails if runtime types are not inferred correctly — perfect regression protection.For even stronger coverage, you might add a variant where the real resource (
foo.vue/bar.css) is absent to ensure the suggested fallback path (see previous comment) still passes, but that’s optional.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/compiler-sfc/__tests__/compileScript/resolveType.spec.ts(1 hunks)packages/compiler-sfc/src/script/resolveType.ts(5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Redirect rules
- GitHub Check: Header rules
- GitHub Check: Pages changed
🔇 Additional comments (2)
packages/compiler-sfc/src/script/resolveType.ts (2)
861-872: Guard against mis-resolving .d.vue.ts – looks correctThe extra check
!file.endsWith('.d.vue.ts')before stripping the trailing “.ts” prevents declaration stubs from being mapped back to the real.vuefile byfileExists/readFile.
That behaviour was the root cause of #13295, so this condition is spot-on.
No further issues spotted here.
1129-1134:parseFilenow requiresfs: please verify all call-sites
parseFile’s signature has changed (parseFile(filename, source, fs, …)), andfileToScopewas updated accordingly.
Please double-check (grep) that no other private helpers inside this module (or tests) still call the old 3-arg version — a silent compile-time break will only show up at runtime in non-TS builds.
edison1105
added
ready to merge
Size ReportBundles
Usages
|
@vue/compiler-core
@vue/compiler-dom
@vue/compiler-sfc
@vue/compiler-ssr
@vue/reactivity
@vue/runtime-core
@vue/runtime-dom
@vue/server-renderer
@vue/shared
vue
@vue/compat
commit: |
|
/ecosystem-ci run |
|
📝 Ran ecosystem CI: Open
|
resolve #13295
Currently, Vue only analyzes types from known type sources such as
.tsfiles and Vue SFCs (.vuefiles). This PR enables Vue to mimic TypeScript 5.0'sallowArbitraryExtensionsoption behavior, allowing type imports from type definitions of unknown type sources (e.g.,.cssfiles).Following TypeScript's documentation, when encountering files from unknown type sources, we will attempt to locate their type definitions in:
./foo.vue:./foo.d.vue.ts./bar.css:./bar.d.css.tsLink to minimal reproduction
https://github.com/Teages/vue-allow-arbitrary-extensions
Related issues
nuxt/module-builder#597
unjs/mkdist#270
unjs/mkdist#268 (comment)
microsoft/TypeScript#50133
Summary by CodeRabbit
allowArbitraryExtensionsfeature, allowing type imports from files with unconventional extensions (e.g.,.d.vue.ts,.d.css.ts).