Quick fix for range operator

[ldez]

Just remove the forced error on ..

Fix #17

[sterpe]

I want to take this, but I don't know what's going to happen now when parsing something like [1..7]. In theory, removing the error is good, but what happens to the whole token stream after that point?

Also the reformatting of code makes this too big of a PR for me to go through. Unfortunately not really much automation/unti testing available to confirm nothing was broken with such aggressive refactor, that's my fault not yours, but makes it hard for me to merge this with any confidence.

[ldez]

can you authorize me to add a better test system (eg not literate coffee and not tape) ?

[sterpe]

Yeah I don't have much time to work on this project anymore (or at the moment anyway). But I'll accept PRs for any unit tests or a fix to the range issue. I do appreciate the work but it would be hard for me to accept the style refactoring that you did.

thanks!

[ldez]

Just out of curiosity, can you explain me what is your influences for this non standard code style ?

[sterpe]

https://docs.npmjs.com/misc/coding-style

[ldez]

ok for "Comma First" but why you declare function as var instead of named function and why you declare all variables in the top of file ?

npm's coding style is a bit unconventional.

I agree with this 😉

[ldez]

I have remove the style refactoring.

[sterpe]

Oh you're right, you know, I think I was just trying some new things style-wise that I don't get to do at work. We can change the style -- I'm not married to it. How do you feel about StandardJS? I use standard for pretty much all newer stuff I've been writing...plus they have an auto reformatter.

https://standardjs.com

[UziTech]

any progress on this? This pretty much makes it useless for me.