Support node paths relative to its source file so I can query them later

[cancerberoSgx]

I would like to have a node path relative to its source file and ideally from any other node so I can locate it quickly later or have a mean of identification. Before I take hands in the problem I would like to know if simple-ast already support something similar (didn't found anything) and author's opinion regarding if this is a good idea / should be in this library scope.

Motivation:

• opening / closing / cloning source files and locate the node I'm currently working on could be hard for nodes deep in the tree
• when modifying the document using insertText, replaceText, or removeText make nodes invalid and I need to query them again. Query nodes again could be hard or cost in term of performance. In this situation would be great if I can do something like const path = currentNode.getNodePath(); newSourceFile.getNode(path) (being I responsible of assuming the changes didn't changed the node's path).

References:

• https://github.com/phenomnomnominal/tsquery
• http://usejsdoc.org/about-namepaths.html
• xml query
• http://goessner.net/articles/JsonPath/

[dsherret]

@cancerberoSgx interesting idea! No, there's nothing like that in the library at the moment.

I think this feature would be a little bit complicated to implement, but maybe not too bad. It should probably work on the underlying TypeScript AST. I'm wondering if it may be better suited in its own library or part of tsquery though... (I'm not sure). What are your thoughts?

By the way, tsquery can be used with ts-simple-ast: https://gist.github.com/dsherret/826fe77613be22676778b8c4ba7390e7

[cancerberoSgx]

@dsherret Nice! - see it working : https://typescript-api-playground.glitch.me/#example=tsquery%20support%20for%20ts-simple-ast

I agree this should be implemented by tsquery or separate library - ts-simple-ast is a big project and adding more and more feature won't scale.

IMO adapting third party libraries based on native TS compiler API like tsquery is a common scenario. The fact that you needed to use getNodeFromCompilerNode to support this case makes me think that from the point of view of extensibilty there should be an API like that exposed to users. do you agree?

Also, tsquery only reads the AST; for more complex libs probably you want to expose emitters when project or AST change. Probably is enough exposing Event emitters in CompilerFactory (already exist for changes in files) but not sure how that wil affect performance. And ideally and going crazy, cancellable event emitters so extensions can validate other's / user's modifications. But that's too much.

I see there is SourceFile.onModify but it doesn't tell me anything although can cover lost of cases, but still I'm not finding a way of being notified when a file / dir is added to the project.

[dsherret]

I'm going to mark this one as out of scope for this library. It would be more beneficial for this to be implemented as a separately library working on the TypeScript compiler API's AST directly.