Add type and characters options

[stroncium]

Added type and character options, fixes #2

[sindresorhus]

It's a little bit awkward to have two mutually exclusive options, but I couldn't think of a better way to handle it. Can you?

[stroncium]

@sindresorhus If it was me, I'd just do exports = { xxx: function } instead of exports = function in the first place, but now that it is the way it is I don't think making a breaking change out of this feature is a good idea.

I do think that that using function.function is misleading, so it's probably best to leave it as it is.
I don't think it will be confusing for users in reality, it's hard to expect someone using anything but constants for this parameters and the intent it passed clear enough. For the purpose of code maintenance, after this update the library functionality will be full(in terms of nothing to add except maybe additional predefined character sets), so it should be ok too.

[stroncium]

re: characters string length
forgot to check it before. 65536 is a sane limit(all characters javascript supports) even though technically library supports using using same character multiple times allowing for changes in distribution. I don't expect anyone in lifetime of this library to actually use this feature and require a length of more than 65536, and cutting it to 65536 allows us to require less entropy and run faster.

[sindresorhus]

Should we have a minimum amount of characters? Doesn't really make sense to only have two characters, for example. Can you also mention the entropy aspects of the amount of characters to choose? And a recommended minimum maybe?

[stroncium]

Don't see any problem with strings length 2. Why not have random string of 0 and 1 for example. Length 0 isn't computable though, so obviously is a limit. Length 1 technically is valid, though isn't random, but to prevent this type of user errors we also need to check unique glyphs, which IMO is a bit of overkill.

Can you also mention the entropy aspects of the amount of characters to choose?

Don't really understand what are you pointing at. If user doesn't know what entropy is we need to include whole lecture on information theory, and if he knows what entropy is then there is nothing to explain.

[stroncium]

Which one should we use though, with brackets and separate line, or without? In execa I was suggested the opposite changes and they were accepted in the end.

[stroncium]

For the record I myself is in favor of brackets+line for better intent indication and readability.

[sindresorhus]

Which one should we use though, with brackets and separate line, or without?

This format. Like you said, it makes the intention clearer. I do this for all code. I only use inline arrow functions when they are meant to return something.

In execa I was suggested the opposite changes and they were accepted in the end.

That must have been an oversight. Fixed: sindresorhus/execa@f6db264

[sindresorhus]

Looks good 👌