Zero-padding not supported in compiled output
Closed this issue · 4 comments
It appears that zero-padded numeric sequences are advertised, but not properly supported.
// Example from README.md
console.log(braces('a/{001..300}/b')); //=> ['a/(0{2}[1-9]|0[1-9][0-9]|[12][0-9]{2}|300)/b']
// Actual output is:
[ 'a/(0{0,2}[1-9]|0?[1-9][0-9]|[12][0-9]{2}|300)/b' ]
Will follow up with PR with failing test cases.
Please advice whether the fix for this is in this module, or upstream in to-regex-range.
As always, thanks for you hard work on this module and so many others.
Okay, I dug into this a bit more...
It seems that fill-range is the culprit, and 'to-regex-range' is not actually used. The undocumented strictZeros
option can be passed to fix zero-padding in braces
.
assert.deepEqual( braces(['a/{01..20}/b', 'a/{1..5}/b'], { strictZeros: true } ), [ 'a/(0[1-9]|1[0-9]|20)/b', 'a/([1-5])/b' ] );
My recommended solution here is to make { strictZeros: true }
the default behavior in braces
, since ( to my mind anyway ) it represents a more correct output, leaves fill-range
intact and still allows overriding to non-strict zeros.
Thoughts?
The undocumented
strictZeros
option can be passed to fix zero-padding inbraces
.
Thank you, I had a hard time remembering and was about to look. Yes, I agree with that. However, I think we should do a major bump because it will result in a breaking change. Would you like to do a PR?
FWIW I have a couple of other fixes that I'll be publishing as a patch before I bump the major.
I will make a PR for this in the next few days, making { strictZeros: true }
the default behavior and adding docs and test cases. Is there any reason to use to-regex-range
, or is fill-range
sufficient?
This should be resolved by #29. Another change needed to be made in fill-range to ensure that padding was applied.