How to clear plugin-run-script's dashboard between edits

[firefish5000]

The problem

Output on the dashboard is not magically cleared between file changes by plugin-run-script. This means that the output generally duplicates between saves, making for extremely long and dubious dashboards full of old and irrelevant data.

After saving a file 2 times, a dashboard might look something like this

error   src/utility/i18n.ts:2:39 @typescript-eslint/no-unused-vars 'get' is defined but never used.
warning src/utility/i18n.ts:15:7 no-console Unexpected console statement.
error   src/utility/i18n.ts:43:7 @typescript-eslint/no-unused-vars 'fetchL10n' is assigned a value but never used.
warnings 1 errors 2

error   src/utility/i18n.ts:2:39 @typescript-eslint/no-unused-vars 'get' is defined but never used.
warning src/utility/i18n.ts:15:7 no-console Unexpected console statement.
error   src/utility/i18n.ts:43:7 @typescript-eslint/no-unused-vars 'fetchL10n' is assigned a value but never used.
warnings 1 errors 2

error   src/utility/i18n.ts:2:39 @typescript-eslint/no-unused-vars 'get' is defined but never used.
warning src/utility/i18n.ts:15:7 no-console Unexpected console statement.
error   src/utility/i18n.ts:43:7 @typescript-eslint/no-unused-vars 'fetchL10n' is assigned a value but never used.
warnings 1 errors 2

That is the same output, 3 times. First one being the initial load, other two triggered by file changes.
This quickly builds up when you have multiple files and dashboards reporting problems.

The solution

We need to clear the dashboard. plugin-run-script currently looks for \x1bc and will clear the dashboards content if it is encountered. So we can clear the dashboard between file changes by injecting that between runs.

    ['@snowpack/plugin-run-script',{
      cmd: 'FORCE_COLOR=1 svelte-check --output human', 
      watch: `chokidar "src/**/*.{svelte,svx}" --initial --silent -c "echo -e '\x1bc'; $1"`,
      name: 'svelte-check',
      output: 'dashboard'
    }],
    ["@snowpack/plugin-run-script", {
      cmd: "FORCE_COLOR=1 eslint 'src/**/*.{js,jsx,ts,tsx}' -f vscode",
      watch: `chokidar "src/**/*.{js,jsx,ts,tsx}" --initial --silent -c "echo -e '\x1bc'; $1"`,
      name: 'eslint',
      output: 'dashboard'
    }],

Important new bits include

Command fragment	Why
FORCE_COLOR=1	Force chalk from npm to colorize output despite being used in a pipeline. Only needed if you want colored output
chokidar "<someGlob>"	Use chokidar-cli from npm to watch all files matching the glob <someGlob>.
--initial	Run once right away before any changes occur
-c "<someCommand>"	Run <someCommand> every time the files change
echo -e '\x1bc'	Clear the dashboard between runs
$1	Automatically replaced with contents of cmd field.

Note I used chokidar for watching instead of svelte-check --watch since svelte-check --watch would not clear the screen between file changes.
I prefer chokidar-cli over watchfrom npm since it allows me to narrow down what triggers the dashboard to run and reduce wasted cycles.

[ljani]

I'm having the same problem with ESLint. This solution almost works on Windows as well. However, since echo and command chaining is a bit different with cmd.exe, I need to change the chokidar command to following:

"watch": `chokidar "src/**/*.{js,jsx,ts,tsx}" --initial --silent -c "echo \x1bc && $1"`,

I wonder if there is a portable way to clear the screen. Maybe a Node package?

This should be definitely documented on the web page.

[firefish5000]

You could call node's write directly, should be relatively simple. I just used echo since it is a simpler and shorter oneliner.

[ljani]

Interesting enough I think this made my tests fail on Docker. It took me a while to find the error as playwright seemed to hide it from the output:

[eslint] /root/build/node_modules/chokidar-cli/utils.js:16
        throw new Error('$SHELL environment variable is not set.');
        ^

Error: $SHELL environment variable is not set.
    at Object.run (/root/build/node_modules/chokidar-cli/utils.js:16:15)
    at run (/root/build/node_modules/chokidar-cli/index.js:217:18)
    at invokeFunc (/root/build/node_modules/lodash.throttle/index.js:160:19)
    at leadingEdge (/root/build/node_modules/lodash.throttle/index.js:170:22)
    at debounced (/root/build/node_modules/lodash.throttle/index.js:235:16)
    at invokeFunc (/root/build/node_modules/lodash.debounce/index.js:160:19)
    at trailingEdge (/root/build/node_modules/lodash.debounce/index.js:207:14)
    at Timeout.timerExpired [as _onTimeout] (/root/build/node_modules/lodash.debounce/index.js:195:14)
    at listOnTimeout (node:internal/timers:555:17)
    at processTimers (node:internal/timers:498:7)

[firefish5000]

While chokidar-cli is a command runner that depends on the shell, execa (which plugin-run-script uses internally) is pretty much the same. So unless you specify file paths to your executables, I would imagine just using plugin-run-script would cause the test to fail... idk. My understanding of how binaries are resolved by child_process and execa is incomplete.
The fact chokidar ran means execa can find it, so I guess node_modules/.bin is a path it checks without bothering the shell. Or maybe execa just has better code for guessing the shell than chokidar

[FredKSchott]

Now that we have the onChange API, we could create a new clearOnChange option for the run-script plugin that did something like this:

    onChange({log}) {
      if (output === 'dashboard' && clearOnChange) {
        log('WORKER_RESET', {});
      }
    },

Is anyone interested in tackling this? Would love the help! If so, I'll spin up a prioritized issue to solve.

Basic overview of the changes needed:

• add the log function to the onChange event (see dev.ts and build.ts for how this is done in the run() hook
• add a clearOnChange option to the run script plugin to enable this behavior (default to true or false?)

[firefish5000]

That certainly adds options, but not sure that a clearOnChange option will work with the current watch behavior. Issue is we would have a race condition between the command's own watch and the plugin's watch. Such as is the case with the example in the plugin's doc

// Sass is watching this directory itself, seperate from snowpack's onChange file watcher.
watch: 'sass --watch src/css:public/css --no-source-map'

If the command's watch runs first, then our plugin's onChange would clear the output after every run and we would always have a blank dashboard. If the plugin's onChange is run while the command is running, half of the new output could get cleared.

It would make more sense to me if we simply hooked into onChange to re-run a non-watching version of the command (like the contents of the cmd field) so we don't have 2 separate file watchers competing with each-other. This is something the onChange api with a log field certainly enables us to do as well.

example of how it would be used

{
  cmd: 'sass src/css:public/css --no-source-map',
  // Disable or replace the watch option's functionality do due race conditions it would induce.
  // watch: '$1 --watch'

  // Command to run on every file change. Same as watch, except the plugin does the watching instead of the command itself.
  onChangeCmd: '$1',

  // Only available with onChangeCmd
  clearOnChange: true
}

[firefish5000]

But tbh, if we give onChange (and maybe a few other methods like transform) the ability to log, writing a custom plugin for build steps should become easy enough that I would stop using this plugin altogether and write my own plugins instead.
I attempted to do that prior to figuring out how to clear the logs and before onChange was implemented, but hit some roadblock (iirc, the lack of the log function inside anything other than run)