Add validateTypes to stylelint.utils.*

[XhmikosR]

It would probably make sense if the validateTypes were exposed for downstream packages to consume.

Refs stylelint-scss/stylelint-scss#554

EDIT: looking at stylelint-scss code, it seems they duplicate a lot more utils.

[ybiquitous]

Since the utils are private and cannot be changed easily in the future, it seems not good to me to expose them. 🤔

[jeddy3]

We'll need to weigh up the convenience for plugin authors against the costs of a broader public API for ourselves.

We expose 4 utils:

• stylelint.utils.report
• stylelint.utils.ruleMessages
• stylelint.utils.validateOptions
• stylelint.utils.checkAgainstRule

validateOptions is interesting as it's not needed to create a working plugin, but is very useful. Exposing the validateTypes functions would complete this picture.

There are other utils that are stable in responsibility, e.g. the isStandardSyntax* ones, but I'm less convinced of their value against the costs of a broader public API.

There's no obvious right answer here, we'll need to pick what we think is the best compromise.

[jeddy3]

There are other utils that are stable in responsibility, e.g. the isStandardSyntax* ones...

Example of the isStandardSyntax* being used in the wild.

(As an aside, it looks like a new version of the validator is going to land soon with support for at-rules!)

[ybiquitous]

Example of the isStandardSyntax* being used in the wild.

Interesting. Exposing such helper functions may be valuable...?

(As an aside, it looks like a new version of the validator is going to land soon with support for at-rules!)

This is very promising! 🙌🏼

[jeddy3]

Let's expose validateTypes util for now as it's complementary to the already exposed stylelint.utils.validateOptions.

We can revisit the isStandardSyntax* utils (in a separate issue) when get around to #5291 and bundle.

[ybiquitous]

I'm reconsidering this issue inspired by #6151. What if starting with the following changes?

• Expose only is*() functions. Because I'm still not confident with assert*() interfaces, but is*() interfaces seem more stable.
• Expose functions as flat forms, e.g.

  // A bit verbose
  stylelint.utils.validateTypes.isBoolean(value);
  
  // Simpler
  stylelint.utils.isBoolean(value);

[jeddy3]

Adding only the is*() functions to the public API sounds good to me as they're the most commonly used alongside stylelint.utils.validateOptions.

Having said that, I'm not 100% sure of the value of exposing these compared to the reference data which will change over time whereas the type checks won't. A person can, if they wish, copy and paste them into their plugin confident that they are unlikely to change.

[ybiquitous]

Having said that, I'm not 100% sure of the value of exposing these compared to the reference data which will change over time whereas the type checks won't. A person can, if they wish, copy and paste them into their plugin confident that they are unlikely to change.

I also have the same concern. Again, the more we expose, the more we have to think about when releasing.

[jeddy3]

Closing in favour of broader discussion issue #6866