Wildcard Support

[usernotnull]

Hey,

I wanted to add a suggestion, and in your git template, the feature suggestion opens a discussion chat, but since this repo doesn't have discussions enabled, it leads to a 404.

Instead of spamming you with another issue, how about I also add the feature request here :)

Would it be possible to include wildcard support for the exclusion list?
The clockwork library has a lot of keys in the env file which are generated, but in production, clockwork is not installed, so having them in the env file is useless.

I could manually add the 46 generated keys by this library in the exclusions config key, but how about having the option to instead add a 'CLOCKWORK_*'?

[olivernybroe]

Great idea 💡

And thanks for pointing out the issue with discussions being disabled, I'll enable it 👍

[lukeraymonddowning]

One thing we'd have to check is if '*' is a valid character for ENV variables. If it is, we could run into a specificity issue.

[usernotnull]

These strings have the form name=value; names shall not contain the character '='. For values to be portable across systems conforming to IEEE Std 1003.1-2001, the value shall be composed of characters from the portable character set (except NUL and as indicated below). There is no meaning associated with the order of strings in the environment. If more than one string in a process' environment has the same name, the consequences are undefined.

Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the '_' (underscore) from the characters defined in Portable Character Set and do not begin with a digit. Other characters may be permitted by an implementation; applications shall tolerate the presence of such names. Uppercase and lowercase letters shall retain their unique identities and shall not be folded together. The name space of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this name space without modifying the behavior of the standard utilities.

See https://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html

From the above, it's true, * is allowed, see the char set here

I can't think of a reason to use the asterisk as a key instead of a value, but we could allow the user to choose to toggle wildcard support in the config file, covering all case scenarios.

[olivernybroe]

We could make a small wrapper class, e.g.

'exclusions' => [
	Exclusion::wildcard('CLOCKWORK_*'),
	'OTHER_ENV',
	Exclusion::make('THIRD_ENV'),
]

So behind the scenes we always map to exclusion objects, making exclusion an interface, with a simple apply method. This way you can even create crazy custom exclusions, but by default we ship with the full match and wildcard match 🤔

[lukeraymonddowning]

Ooh, I like that. Although whilst we're adding it, we could add Exclusion::regex() too 😎

[lukeraymonddowning]

#5

Here's a PR for this functionality.