gron parses differently when key has non-alphanum char about gron

[tomnomnom]

Hi @dbabits!

I'm afraid this is by design. Gron's output is a subset of JavaScript - in the same way JSON is a subset of JavaScript (or at least it nearly is). A big reason for this is to ensure that the output is easily parseable by gron -u / gron --ungron, and not surprising to people that are already familiar with JavaScript syntax.

- isn't valid in a JavaScript identifier / variable name so it has to be quoted.

There's some discussion of a similar issue in issue #30. If you're after an output format that is less strict but more consistent, you might find the tool I wrote and linked to in a comment on that issue useful.

I know this probably isn't the response you're after, but I'm afraid I'm not prepared to change gron's output format at this stage. Thanks for raising the issue all the same!

[dbabits]

@tomnomnom,
Thank you for your response. But, why not quote always-wouldn't it address the issue while being valid JavaScript?

[tomnomnom]

@dbabits that's a good question. In hindsight I think that would probably be the right thing to do. I do think the non-quoted version is easier to read where it's possible to use it, but the simplicity gained by always using the quoted version would probably have been a worthwhile trade-off.

I'm not a fan of breaking changes, so I think it's just going to have to stay the way it is. Ah well; you live and learn :)

[dbabits]

@tomnomnom
Thanks Tom. I'm not a fan of breaking changes either, but it could be justified in this case.
Consider: gron is probably often used in a pipeline (that's the whole idea):

cat json | gron | parse

The parse part has to handle both cases shown above which makes it more complicated than necessary.

Worse, probably many people (judging from my own experience:) will only code the first case, only to see their application break when data changes to include some new character, maybe long time in the future.

In my experience, it was difficult to debug, because data just didn't make it downstream(pattern didn't match - no errors), and it wasn't noticed, and when it was - it took quite an effort to try to understand why and to replicate.

So, I would rate it as a bug.
At a minimum, I think we should document it. Fixing is even better:) (maybe with a switch for backward compatibility?)

Thanks!