Incorporate error improvements from/for YAML Doctor

[Mr0grog]

Hi, I recently did some consulting work for Asana, where I wound up implementing some tools to provide clearer error messaging and advice when people write invalid YAML code. They’ve been generous in letting me open-source it as “yaml-doctor”: https://github.com/Mr0grog/yaml-doctor

I’m sure not everything in yaml-doctor is really relevant to js-yaml, but:

1. Some things it does are pretty simple (e.g. using nicer language and adding a bit more information to the “deficient indentation” warning), and it would be nice to incorporate them directly into js-yaml.

   Would some of these changes be welcome?

2. Other things it does are a lot more complicated or even speculative (e.g. handling anchors that look they were meant to be HTML entities at the start of a scalar), so I imagine you wouldn’t want them in the parser.

3. Many things rely on the listener callback, which I know isn’t totally stable, and would be aided by potentially having better hooks into the parser (e.g. an opportunity to intercede before an error, or rewind to the start of the last token, or more information about the current parsing context).

   Would some design ideas (and work on implementation) for this be welcome?

I’m more than happy to work on these things, but I wanted to check in with any maintainers or active contributors here before showing up with a bunch of random or even unwelcome PRs. :)

[puzrin]

Things like syntax coloring and linter is class of task, which require AST. Current implementation does not have it (listener callback is dirty hack). So, i suspect, that trying to incorporate some improvements will be very hacky.

Ideally, this package need full rewrite, more close to reference libyaml implementation (with "events" layer). But with keeping in mind some JS practices to keep speed high. I have no resources for such rewrite, but all "ideas" are collected in #331.

---

In short: i'm ok to accept any non-hacky improvements. But you need to decide first, how many time do you wish to spend (improve v3 a bit, or do v4).

[Mr0grog]

OK, sounds like I should start with just doing some simple things like better wording for some errors if there might be a big rewrite in the future.

Things like syntax coloring and linter is class of task, which require AST.

FWIW, YAML Doctor focuses on better parser errors and enabling the parser to go farther and find more errors before totally failing, so an AST wouldn’t necessarily help it. Most of what I’m doing is only applicable if js-yaml would have failed to create an AST in the first place. YAML Doctor isn’t really a linter in the traditional sense.

[puzrin]

I'd suggest to prepare PR with 1 simple change, and i can say exactly then, if those can be merged or not. If everything ok - then you could add the rest there.

[puzrin]

Close as outdated (due inactivity)