Whistle Plugin Development - remote-rules

Recently, the company provided a cloud IDE service, allowing some development work to switch from local to remote machines. At the same time, the frontend is moving towards micro-frontends, which always require proxies during development. With the emergence of the cloud IDE, the proxy address will change with the IDE address, which drives the need to solve the problem of loading remote proxy rules with one click.

The overall development process with cloud IDE:

1. When the task management system issues a story
2. The developer creates a feat/fix branch, CI automatically creates a cloud IDE development environment and a new Whistle proxy rules file
3. CI sends a message informing the cloud IDE address and the Whistle proxy rules file address
4. The developer clicks on the Whistle proxy address to directly load the rules
5. The developer starts coding

The advantage of this is that developers don’t have to manually maintain proxy rule files.

To solve this need, I started Whistle plugin development and found that Whistle provides scaffolding tools and some demos, making the overall development process relatively smooth. However, some issues are not clearly described on the official website, so I will briefly summarize them here, which may help some peers.

Development

The general implementation logic is as follows:

1. Use the UI Server to expose a new URL for the Whistle web service, supporting the remoteRules parameter
2. Handle the parameter in the plugin UI router, download the rule file based on the parameter value, and save it temporarily
3. Call the Whistle command w2 add to load it
4. Redirect to the Whistle web rules page

Plugin installation and source code click here, which may help some people.

Usage Effect

$ npm i whistle -g

$ npm i whistle.remote-rules -g
# or

$ w2 i whistle.remote-rules

Automatically load remote rules, address template as follows:

http://local.whistlejs.com/whistle.remote-rules/?remoteRules={url}

For example:

http://local.whistlejs.com/whistle.remote-rules/?remoteRules=https%3A%2F%2Fgist.githubusercontent.com%2Falanhg%2Fa950d216121002d5bb0fd1278789da75%2Fraw%2Fc8bdf23e05c9dc504ea393a0b373cb556df911d8%2Ftest-whistle.js

With this plugin support, CI can directly push the above address. After the developer clicks to load it, they can continue development and debugging.

Notes

Some aspects of the Whistle official documentation and examples are not very clear, so I will supplement them here.

1. Plugin debugging

# If Whistle is running, you need to manually stop it
$ w2 stop

# Run Whistle in debug mode; exceptions or console prints from the plugin script will be printed in the terminal where the script was started
$ w2 run

2. Plugin development, hot reload

# Real-time compilation when modifying scripts, needed for TS development
$ npm run dev

# Monitor dist and rules files; if there are fixes, the loaded plugin will be automatically updated, and the terminal will print reload information
$ lack watch

3. Publishing

Plugin publishing does not require pushing to the Whistle author’s repo or whistle-plugins organization. You can publish it under your own name. Just note that Whistle uses package names to ensure recognition, such as whistle.remote-rules which I developed.

4. Whistle-server

Whistle provides multiple servers; choose the corresponding server based on your needs. For example, if you need to expand UI services and implement custom pages to perform certain actions, such as exposing URLs and automatically downloading remote rules as I did here, you should rely on uiServer, and the router corresponds to some APIs or sub-route pages you implement.

Final Thoughts

Whistle exposes interfaces that support extending proxy features based on personal needs, which is very impressive.