fix(ts): force mandatory options

[bitPogo]

Closes #10573

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

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

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

• Yes
• [ x ] No

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

The PR fulfills these requirements:

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

If adding a new feature, the PR's description includes:

• [ x ] 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:
Example: https://tinyurl.com/y2uzn6k2

[posva]

Could you add tests to the plugin-test.ts file in the types folder:

• One that checks that we can use a plugin that takes no options
• Another one that checks we can use a plugin with optional options both, with a second parameter, and without

[posva]

this one should yield an error though 🤔

The tests that must be added are:

function NoOptions(_Vue: Vue): void {}
function OptionalOption(_Vue: Vue, options?: Option): void {}

Vue.use(NoOptions)
Vue.use(OptionalOption)
Vue.use(OptionalOption, { prefix: '', suffix: '' })

I'm realizing that the types you put in vue.d.ts are different from what you tried on the TS playground

[bitPogo]

It passes also in current dev

Thanks for that advises.

Indeed is a minor difference to the mentioned playground. The reason is
Vue.use(installer, new Option, new Option, new Option);
Would fail, since the definition hits in the master the any case of use, which would not work with unknown. (I am even not sure if this was intended in the master)

[bitPogo]

Please let me know, if the any fallback was intended on Vue.use<PluginOption>. This could behavior could be restored by a additional definition use<T>(plugin: PluginObject<T> | PluginFunction<T>, option1: any, option2: any, ...options: any[] ): VueConstructor<V>;. It looks perhaps a bit odd, but use and a given type should fallback at n+1( n>1 ) arguments toany according to master.
( Please see: https://tinyurl.com/y3lcapvv )

[posva]

The typeof shouldn't be necessary, maybe we should use PluginFunction<never>, also it's better to use an uppercase version like _Vue or Vue

[bitPogo]

Since is defined as PluginFunction<T> = (Vue: typeof _Vue, options?: T) => void; the compiler will complain on a direct usage of Vue as a type. I changed it to VueConstructor, so it should be clearer.

[pkf1994]

Test

[posva]

@pkf1994 This is the 3rd time you spam with tests. Don't do it again or we will have to block you.

[bitPogo]

Since this is now ancient...I am closing it - happy new year!