Feature request: visit() is not useable with modify()

Xem lại phần Why của tài liệu và các entry point visitor, parseTree, modify và applyEdits được nêu trong issue. So sánh workflow visitor-to-edit được yêu cầu với các ràng buộc của offset/length và JSONPath. Được xem là hoàn tất khi có một đường dẫn chỉnh sửa dựa trên visitor được hỗ trợ hoặc tài liệu rõ ràng hơn về workflow được hỗ trợ, đồng thời cập nhật các test và tài liệu tương ứng.

node-jsonc-parser presents several convenient ways of interacting: The scanner, the visit interface, or traversing a parse tree. Unfortunately, only the parse tree interface is compatible with modify/Edit/applyEdits. This means there are essentially three interfaces, but two are read-only.

Context

I have a lot of JSON files, from which I want to remove all instances of a particular deprecated property. I intended to use node-jsonc-parser to write a script to find those instances and delete them. At first I thought the Visitor interface would offer an incredibly simple way to do this; I could write a single JSONVisitor:

let edits:Edit[] = []
visit(jsonString, {
	onObjectProperty: function(property: string, offset: number, length: number, startLine: number, startCharacter: number) {
		if (property == "cursedPropertyName") {
			// Do something here to add "remove this property" to edits?
		}
	}
})
jsonString = applyEdits(jsonString, edits)

The realization I quickly hit was there is no way to create the Edit to move the property. modify() requires a JSONPath, obtaining a JSONPath (eg, findNodeAtLocation) requires providing a node or a root node (which means running the parse interface). I could create an Edit object manually with the offset and length of the property, but this might mean creating a noncompliant JSON document (eg, if I removed a property but not the preceding comma).

Expected behavior

There should be some way to use the convenient visitor-style interface with modify()/applyEdits(). Two ways I can think of to do this would be

1. Add a Node.visit() interface. The reason I would prefer to use the visitor interface rather than parseTree is parseTree required me to write code to recursively traverse the tree of node children, a somewhat complicated construction for a simple find/replace script. However, jsonc-parser could just as easily provide a visitor interface to node trees, calling a visitor function and passing in the appropriate node for each node in the DOM tree, eg calling onObjectProperty for each NodeType="property" node.

2. Add some variant of modify() that works with the offset/length arguments, but still knows how to produce edits that transform from a compliant JSON document to a compliant JSON document, eg, it also removes incidental material like whitespace and commas as appropriate. This option might be harder due to ambiguity about what to remove.

Another thing that would help would be simply being clearer in the documentation about what is supported. Writing my script once to use visitor and then starting over with parsetree was a bit frustrating, but if I had known to start with parsetree, I could have skipped the steps of trying to make it work with scanner and visitor and that would not have been frustrating. The documentation could make this clearer by, in the "Why" section, between the third and fourth bullet points, adding the non-bulleted text "Using parseTree enables the following extra functionality:".