-
-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add type
and characters
options
#4
Conversation
type
and character
options
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? |
@sindresorhus If it was me, I'd just do I do think that that using |
re: characters string length |
readme.md
Outdated
|
||
Type: `string` | ||
|
||
Setting this option makes it select characters from the string. Can not be set at the same time as `type`. Maximum length 65536. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
type
and character
optionstype
and characters
options
|
||
test('argument errors', t => { | ||
t.throws(() => { | ||
cryptoRandomString(Infinity); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the record I myself is in favor of brackets+line for better intent indication and readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Looks good 👌 |
Added type and character options, fixes #2