refactor: move @babel/helper-validator-option to ts

[JLHwung]

Q	A
License	MIT

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 81b34ac:

Sandbox	Source
babel-repl-custom-plugin	Configuration
babel-plugin-multi-config	Configuration

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/35001/

[nicolo-ribaudo]

Actually, value could be anything here I think (otherwise we wouldn't need this helper).

[JLHwung]

Ideally value should be of type that extends string. So if we accidentally pass number value to validateStringOption, the type checker should throw.

[nicolo-ribaudo]

Couldn't it be anything, since it's whatever the user gave us as input? We cannot statically know the type of plugin options, so an user could pass a number to a plugin, the plugin will pass a number to this helper, and then this helper will throw.

[JLHwung]

We also offer our type interface to programmatic users:

{ a: any, b: any }

is technically correct (which is the type user inputs) but not much of value for programmatic usage (API caller) and/or schema check. The validator here is a runtime enforcement of type checking -- so the user input does match our assumption of types, so it makes sense that if the type checking is good, it is also sound in runtime.