Copy line number feature does not copy the entire path

[ialecse]

Whenever the Copy line number feature is used it never copies the parent folder, but stops right before it. Most add-ons have a structure with multiple folders and it's important to get the entire relative path from VSC.
As an example we have the following structure

• Parent Folder 1
  -> Sub Folder 1
  => file1
  -> Sub Folder 2
  => file2
• Parent Folder 2

If the Copy line number is used in file1 the path will be */Sub Folder 1/ file1#L12(For example), but the correct path should be Parent Folder 1/Sub Folder 1/file1#L12

[chrstinalin]

To which folder is your VS Code opened to in your example, in relation to the GUID? It seems I'm unable to replicate this issue. Explicit steps to reproduce would be very helpful, if you're able.

[ialecse]

I opened a new folder with VSC -> File -> Open Folder -> Select Folder, that has the following structure ( just an example)

From the js/background.js file if I select a line with Copy line number I get " * #L10 " , not "js/background.js#L10"

[chrstinalin]

Are you saving the add-on through Assay/opening it through Reviewer tools, or was addonfolder manually saved into the root folder? If the latter is the case, could you try saving the add-on through either of the first two methods and see if the issue persists?

This occurs because Assay expects a version folder between the add-on guid and the contents of the add-on. So in the given example, it expects

addonfolder
  | versionfolder
     | js
        | background.js

But, if versionfolder is not present, causes this problem.

[ialecse]

When an add-on has source code we cannot save it through Assay, it must be saved manually and most add-ons are in this situation. Can this feature be made available for this case as well?

[chrstinalin]

Assay was originally meant to release with this feature (and was even implemented) but ended up being pushed to a future "version 3".

I can ask to bring the priority of this up.

Are there any other similar use cases for you Assay hasn't covered? If there are, now would be a good time to file issues for those as well, so they can be planned into version 3.

[chrstinalin]

Given:

guid/version/foo/bar/file.txt

and

guid/foo/bar/file.txt

There's no way for Assay to reasonably make the distinction that foo is not a version number, and much of Assay is dependent on the asssumption that the version folder does exist (as it assumes files were installed through Assay, so it can also correctly populate metadata).

Thus, Assay should not officially support manual installations.

The fix to this issue would then be to:

1. Introduce source code installations through Assay (Open a Source Code Package for Review #59)
2. Discourage the user from manually installing anything to the root folder by taking on more control of the root folder from the reviewer. I.e install the add-ons to the .cache folder, and encourage reviewers to interact with add-ons exclusively through the Assay extension.

Since 1) should effectively prevent this issue from occurring in an official capacity, I'm changing this from a bug to a nice to have.