[rush] VSCode Extension

[chengcyber]

Summary

This is a topic in last Rush Hour Event to create a VSCode extension.

Background

There are two roles in a monorepo: Repo maintainer and developer. Though the configuration of rushstack becomes heavier with more features shipped, it’s still acceptable to repo maintainers. But it’s not a good tendency to lift more mental models into general developers. A general case is after the developer pulls code from the main branch, and the project may be “broken”, rushx dev not working anymore. But the solution is quite simple: run rush build –to-except . to build the dependencies in monorepo.

Requirments

1. Improves developer experience, better adaption for developers’ daily commands
2. a GUI can show more recognizable information.

Usage

Assuming a monorepo structure as follow:

apps/my-app libraries/my-lib

1. List scripts for each projects

apps/my-app/package.json has three scripts: dev, build, test libraries/my-lib/package.json has three scripts: dev, build, test

- @scope/my-app           <status> <action:reveal in explorer>
  |- dev                                                            <action: run>
  |- build                                                          <action: run>
  |- test                                                            <action: run>
- @scope/my-lib            <status> <action:reveal in explorer>
  |- dev                                                           <action: run>
  |- build                                                         <action: run>
  |- test                                                           <action: run>

Project status

project status indicates information of this project: node_modules installed? all dependencies in monorepo have been built?

Action: reveal in explorer

A quick action to focus on the project folder in vscode file explorer.

Action: Run

Run the script when click

2. List rush command lines

Display the rush commands

>_ install
>_ build
>_ update

Current parameter definitions might be involved to declare how to interact with users. And custom command lines from rush plugins can be extended to be used in VSCode extension as well.

Interact with users by prompts

Use install as an example here, when user clicks >_ install, prompt user to set up parameters

• purge
• bypass-policy
• no-link
• network-concurrency
• debug-package-manager
• max-install-attempts
• ignore-hooks
• variant
• to
• from
• only
• impacted-by
• impacted-by-except
• to-version-policy
• from-version-policy
• check-only

When a user clicks a String, Number type parameter, another input prompts the user.

Like click “to”, user inputs “my-app”, and then press Enter. Then, the command becomes “rush install –to my-app”

When a user clicks a boolean, Enum Type parameter, another input prompts the user.

Like click “check-only”, user selects from “true” or “false”, assume “true”, then the command becomes “rush install –check-only”

Interact with users by UI

When a user clicks a command, opens a new tab, displays whole settings by command parameters.

3. Register rush command lines into VSCode commands

Invoke rush commands by VSCode command palette.

For instance, user inputs > rush: install in the command palette and press Enter. It should be the same as clicking the command in the extension tree view container.

Resource

https://github.com/nrwl/nx-console

[Faithfinder]

A concern I would have is multi-root-workspace interactions. Ideally that should be taken into account immediately. For example, I often enough have 2-3 rush repo roots open in the same workspace, and some of the projects from them open as separate folders. A good extension shouldn't be confused in a setup like that.

[chengcyber]

My idea is the extension should treat welbi-core as the current workspace, and the user can switch to another one by clicking the switch workspace button

[Faithfinder]

The main thing is to detect repos correctly (for example, in the screenshot, there are three). If that's done then tweaking interfaces should be easy. I'd probably make choosing the repo a first step in whatever command is running (if there's more than one repo)

[chengcyber]

As far as i can see, the internal logic would be like iterating over welbi-core, welbi-rush, api-node, welbi-ui sequentially, and if rush configuration can be loaded from any of them, stop immediately and use this rush configuration as current workspace.