add option to define only `yes:`

[Muescha]

since a case misspelling is sometimes not that predictable, i suggest only to have the right word:

{ yes: "WordPress" },
{ yes: "TypeScript" },

when there is a missing no: value then the regex is should be constructed from the yes: but case insensitive

[Rich Trott]

I'm thinking about making it always be a case-insensitive match and doing a semver-major bump.

The downside is less configurability/control over the behavior. However, I don't think anyone ever wants any other behavior, and so the upside is it just does what people want/expect right out of the box.

[Muescha]

I would also suggest:

Allow also if there is only a string, then no need to repeat the text

[
       "End-of-Life",
       "GitHub",
       "JavaScript",
       { no: "node\\.js", yes: "Node.js" },
       "RFC",
       "Unix",
       { no: "RFC\\d+", yes: "RFC <number>" },
       "V8",
       { no: "Windows Store", yes: "Microsoft Store" }
]

[Rich Trott]

I'm not sure it's obvious what it means when there isn't a no string. I'd prefer it be explicit, although then again, there's certainly the problem of this being surprising: { no: 'foo', yes: 'foo' }....

[Rich Trott]

Especially given the name of the plugin is prohibited-strings, I would expect a bare string to list a string I should not use, rather than a string I should use.

[Muescha]

oh - yes, thats somehow confusing :(

on one hand it is DRY to use the same string, and a shortcut would be nice.
but on other hand it is confusing or problem that user forget that this is a regex (like with a "Node.js", }

but a user who like to avoid DRY he can self do a .map over the array to make from string a {no:"",yes:""} object

[Rich Trott]

Thinking about this one some more:

• I prefer explicit code since it will be read more often that written, but that is also just my preference. If some people prefer succinct code, the module can offer that and I don't have to use it.
• It would seem to make sense to allow people to specify a no without a yes. Then the string is prohibited and a suggested correction is not offered.
• The request here, to permit a yes without a no, then starts to make a bit more sense to me.

[Rich Trott]

This feature is now available in 1.5.0. Closing, but please re-open or comment if it isn't doing what you requested!