Have different vscode-ibmi actions by directory

[bspotswood]

I've been using these extensions for somewhat sizable project at the day job and I'm not at the point of doing some form of customized unit tests. I've had to build some extensive functionality into our actions using bash scripts that get run in PASE. It's working well for our kind of weird use case, but now I'm adding other source in and making a unit test framework.

I want the actions to be different based on the path that you're in.

• Actions available under src/ should be different than under test/

I tried seeing what happens if I just created a .vscode/actions.json under a different path. I was intrigued to find that it merged all the actions together rather than making them distinctly available.

So then looking at the code, I see the simple tests that are going on for deciding which actions to present:

vscode-ibmi/src/ui/actions.ts

Lines 71 to 77 in f59c151

	// Then we get all the available Actions for the current context
	availableActions = allActions.filter(action => action.type === uri.scheme && (!action.extensions || action.extensions.includes(extension) || action.extensions.includes(fragment) || action.extensions.includes(`GLOBAL`)) && (!isProtected || action.runOnProtected))
	.sort((a, b) => (actionUsed.get(b.name) || 0) - (actionUsed.get(a.name) || 0))
	.map(action => ({
	label: action.name,
	action
	}));

I feel like it would be easy enough to implement a couple of options:

1. Write down the parent path of the .vscode folder on the action object and compare it against the file root
2. Allow for a new attribute on the action definition, such as a path, that restricts where the actions are presented. This could be a pattern.

There might be other good options as well, but these two make sense to me.

The first option I gave would have you putting the action definitions in different files and maybe cluttering the file system more, but the tradeoff is that you have pretty clear separation between them.

The second option keeps them in one file (although two+ is still an option since it already merges them), but requires you to maintain that path if you move files around and can clutter the contents if you do decide to keep them all in one file (if you have a lot of actions).

I have no problems putting together a PR for this, but since I've not been working on this code base I for sure would like some feedback on any preferences for this kind of thing and if it is even going to be acceptable.

I think my preference would be the first one, where it will track the path to the .vscode folder it found the actions in and then only present actions that have a common root somewhere up the path.

[worksofliam]

A great idea indeed, I am excited to hear Seb chime in here.

My simple thoughts:

• default to .vscode/actions.json for actions, or
• find the next actions.json in the parents of the working directory. For example, I am working in src/partA/qrpglesrc/scooby.rpgle, then first look for src/partA/qrpglesrc/actions.json, then src/partA/actions.json, and so on. This is similar to how package.json works with npm.

[bspotswood]

Since it was already doing one scan of the file system for **\.vscode\actions.json, I was thinking of having it filter that against the target file(s) for the actions based on the target file(s). Here's an example commit with that change:

bspotswood@0e36764

• Add targetPaths?: Uri[] parameter to getLocalActionsFiles
• Still uses the same workspace.findFiles call to scan for actions files
• If called with targets, filters based on parent folders to the .vscode/actions.json sharing paths with target file(s)

I didn't realize actions worked on multiple file selections, but I saw the existing code for it so I made sure to solve for that. It requires that action files are ancestors to all selected files.

Some other things I considered while doing this:

• I saw the normalizePath in Tools.ts, but it didn't seem like it would be useful in this case so I opted not to use it.
• I debated back and forth on path.dirname and path.join vs using Uri.joinPath and opted for the path functions instead since I didn't need a new Uri object for the string based path filtering logic
• File system case sensitivity: I looked around for other options on case sensitivity for the file system and compare of paths but I wasn't seeing anything that was better than what I put in this example and available to extensions. Looking at examples from vscode's source for examples of how they handle it, I saw a "isLinux" flag that tests the process.platform === 'linux' so that's what I did too.

I've been testing it with this setup:

• There is a common actions file at the workspace root
• The src folder has its own additional actions
• The src path files will present all options from both actions configs
• The test path file will only present options from the root workspace actions script since it cannot see the one under src
• Doing a multiple selection including files from both src and test will only result in it presenting actions from the workspace root since it is the only common path

This is commit is just an example of the logic that I've been toying with. I haven't looked at how to implement changes for the test cases yet for this.

[worksofliam]

@sebjulliand I am looking at this a little more today and the support of running an action against multiple URIs - this will be a very interesting feature to handle.