Include file paths in the /api/read endpoint

[JohnnyMorganz]

File paths should be included in the /api/read endpoint (Maybe behind an optional querystring parameter?, eg. ?showPaths=true)

An example use case for this would be in VSCode when using script to index the current Script/LocalScript/ModuleScript. The path is necessary in order to find the current instance within the DataModel tree, so that it is possible to autofill children and parents

[Dekkonot]

Is this adequately resolved by sourcemaps or should we still do this?

[filiptibell]

If I remember correctly one of the primary reasons for making my sourcemap PR was that this issue (and related PR https://github.com/rojo-rbx/rojo/pull/337) not going through was blocking something I wanted to make, and the design here was unclear. LPG also had a sourcemap PR that was closed (https://github.com/rojo-rbx/rojo/pull/275) and if you follow the links it seems the original issue about an "LSP-like protocol" was more or less the same issue as this here.

[JohnnyMorganz]

For my usecases I would say yes - this is solved by sourcemaps.

Maybe there should be an API to retrieve a sourcemap via a HTTP request? I don't need this though, so feel free to ignore it.

[filiptibell]

Just discovered a use-case for this that sourcemaps wouldn't really solve - auto-discovery of serve sessions for specific project files! Imagine you have a VSCode extension or somesuch that inspects Rojo project files and wants to automatically connect to any serve session for that specific project file. You'd do something like:

1. Read the project file to figure out what serve address/port/default it should use
2. Try to connect to that address
3. Send a request to the /api/rojo endpoint
4. Send a request to the /api/read/root_instance_id endpoint - here's where it currently falls apart - we need the file paths metadata included in the response to verify if this serve session is actually serving the project file we want, and this is currently only available on the "show instances" web page, not from the api
5. We now know that we are serving the desired project file at the found address and can safely interact with the serve session

This is actually something I prototyped and have a real world use-case for already here. Automatically connecting to a serve session (when available) instead of spawning rojo sourcemap --watch would let me skip parsing huge sourcemaps and do manual diffing, improving responsiveness. It could also allow me to use the /api/write endpoint for an editable properties view in the future.