Add test for TOMLParser low-level API stability

[fasterthanlime]

👋 opening this issue to remind myself of this tweet which asks for a test to ensure that the API used in https://github.com/googleapis/release-please/blob/e0c7b00034837d728770fb27ddf6d746c3dd181e/src/updaters/rust/toml-edit.ts remains available throughout iarna-toml releases.

I'm honestly not too sure how I'd go about writing a test like this - maybe extending TOMLParser and making sure the expected "events" are fired? I'm not sure what would even be asserted in the test - should it test the output of the extended parser? Should it test the internal state used in the parser?

I'm sure we can figure something out 😊

[iarna]

Couple of choices:

One would be to literally just clone that repo and see if it can pass its tests. That's probably a bit heavy hand tho. =D

Looks like you're overriding next, parseValue and return. So another option would be write some very targeted unit tests of just those functions. (Currently this module is tested with integration tests and spec compliance tests.)

A third option would be to pull in the class you wrote and bundle it as a another option for the library itself.

[fasterthanlime]

A third option would be to pull in the class you wrote and bundle it as a another option for the library itself.

That would be my (and @bcoe's, I think) favorite option, but I understand it's also a maintenance burden, so I don't want to make that decision for you.

toml-edit as it stands is very handy but limited in scope:

• It will throw on non-existent paths
• It can only replace strings or booleans, but not tables (that would get really complex) or numbers (these are boxed, so their typeof is object - that could be fixed with an additional condition)
• It's pretty much only meant to replace values by a double-quoted string (although I suppose since it's using JSON.stringify, numbers and booleans would also work. Why I didn't use TOML.stringify instead, I'm not sure 😅)

The "parse the result post-string-replace to make sure it's still valid TOML" errs on the "very defensive" side, we could probably replace that with a check that the "value" we're replacing with is a string or a number or a boolean (and not an object or an array).

If you think replaceTomlValue with its current limitations would be a neat addition to iarna-toml, I'd be happy to work on a PR including pretty much the same test suite I've used for the release-please PR - minus the Cargo.toml-centric stuff.

Let me know how you feel about the whole thing, I'm happy to take any of the other choices as well.

[bcoe]

@iarna no pressure, I'm happy to keep floating the implementation @fasterthanlime has provided in releae-please, if we need to.