Handling of Invalid sequences
- Dominant language
- JavaScript
- Stars
- 15
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
Hey,
I'm writing a new tool and your library is a main part of it. Unfortunately how your library handles invalid sequences is causing me issues. I am curious as to how open you are to a small change.
I am creating a plug-in for Atom which will lint a JSON file. The thing is I need to know where in the file an issue is happening at. Since this library tokenizes the white space this becomes very easy to calculate the row/colmun - start/end coords. But in some cases your library throws an error. This happens with something like this
```json
{
"A": "Bad
}
```
or
```json
{
"A": Bad"
}
```
What I would like to see in these cases is a token with a new type, say for example 'invalid'. The library can stop at this point just like it does now. It just would not throw an error. This would mean that if there is an invalid sequence the last item in the array will always be of type 'invalid'.
As an example the two items above create the following 'invalid' tokens
```json
{ "type": "invalid", "value":"B", "raw":"B" }
```
```json
{ "type": "invalid", "value":"Bad", "raw":"\"Bad" }
```
This allows me to mark this spot in the file in Atom as an error. I have already done a small p-o-c to prove this out the above two situations. It was an easy change. I can work to do the rest and create a PR. But I would hate to do that work without checking to see if you are open to changes or suggestions.
Also I can see a config option which will allow someone to indicate if they want an error throw when these items are encountered or not. If true then the library will act as it does today. If false then it will act as I am looking for it to act.
Thoughts?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by inspecting the library's tokenizer and the existing handling of invalid sequences. Confirm how the two malformed JSON examples should produce an `invalid` token, and determine how the proposed configuration controls throwing versus returning that token; done means both behaviors are covered and the token preserves the reported location.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100