What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• It's submitted to themain branch for v2.x (or to a previous version branch)
• When resolving a specific issue, it's referenced in the PR's title (e.g.fix #xxx[,#xxx], where "xxx" is the issue number)
• All tests are passing:https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
• New/updated tests are included

If adding anew feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

When I write a sfc file with js, the type of props inference toany.

<script>//  ^ use jsimport {defineComponent }from'vue';exportdefaultdefineComponent({  props: {    a:Number  },setup(props) {// ^ props is any  }})</script>

ThedefineComponent function allows aProps type to be passed in.
All work fine withts because if not actively passed in this type, the default props type isunkonwn.

But when I usejs to write the code, the default type isany! I think it might be a typescript problem.

I think the problem that went wrong is here.

https://github.com/vuejs/vue/blob/main/types/v3-define-component.d.ts#L153
https://github.com/vuejs/vue/blob/main/types/common.d.ts#L15

options:HasDefined<Props>extendstrue//   ^ here    ?{functional?:never}&ComponentOptionsWithProps<PropsOptions,RawBindings,D,C,M,Mixin,Extends,Emits,EmitsNames,Props>    :{functional?:never}&ComponentOptionsWithProps<PropsOptions,RawBindings,D,C,M,Mixin,Extends,Emits,EmitsNames>

I think Props type should be not defined when it isany . And in that case, typescript would infer the actual type of the props.