feat(enforce-style-type): new rule

[privatenumber]

Closes #101

I ended up naming it acceptCssModules instead of acceptModule because the name is actually plural "CSS Modules".

Thank you

---

I'm also curious if you'd be open to requiring scoping via CSS Modules as well. So instead of acceptCssModules, we do:

{ "cssModules": undefined | "accept" | "require" }

where:

• undefined: Don't acknowledge module
• accept: Accept module in-place of scope
• require: Require scoping via module instead of scope

---

Apr 26 Update:

Implemented the following:

{ "module": undefined | "accept" | "enforce" }

---

May 20 Update:

Implementing the following:

{	allows: ("plain" | "scoped" | "module")[] }

---

May 21 Update:

Moved to new rule enforce-style-type

[ota-meshi]

Thank you for this PR!

I forgot that this rule had the never option 😅.

I think it's a bit confusing for the next test case to report an error.

{ code: `  <template>  </template>  <style module>  </style>  `, options: [ "never", { acceptCssModules: true, }, ], }

I think the <style module> should not be an error (it should be ignore check).

I'm also curious if you'd be open to requiring scoping via CSS Modules as well. So instead of acceptCssModules, we do:

I don't use SFC with CSS modules, so I'm not familiar with it.
If you find the option useful, you can change it.

[privatenumber]

Thank you @ota-meshi

I'll update the PR to have the "cssModules": undefined | "accept" | "require" API this weekend. Where accept does not report an error if never is set and module is found, but will if it's set to require.

[privatenumber]

Sorry for the wait! Ready for review again

[privatenumber]

I'm working on the docs now, and I'm curious what you think about making this a new rule enforce-style-type. Since this rule can enforce that all <style> blocks are plain/un-scoped, it might not fit the rule name "require-scoped".

Making it a separate rule and deprecating require-scoped can also resolve some of the issues mentioned above.

[ota-meshi]

I think it makes sense to deprecate the require-scoped rule and add an enforce-style-type rule. The current rule name has been confused by the addition of options.
However, do not set the category for the new rule. The configuration will be changed with a major version upgrade. Probably the version upgrade will be after ESLint v8 is released.

[privatenumber]

Alright! I think it's ready for another review. Feeling pretty good about this one.

Also, if there's a deprecation method you have for require-scoped, let me know and I can add it.

[ota-meshi]

LGTM! Thank you for lot of work!

[ota-meshi]

Thank you for your contribution!

Also, if there's a deprecation method you have for require-scoped, let me know and I can add it.

I noticed that this plugin doesn't have a deprecation rule yet. The script may not be in place yet. I will do that work.

[privatenumber]

Thank you so much @ota-meshi ! Pleasure to contribute.