Bring up to date with cockpit starter kit

This encompasses a number of changes to the build process.

README.md

@@ -15,7 +15,10 @@ Demos & Talks:
 GitHub Organization: 
  
  * [scribery.github.io](http://scribery.github.io/)
- * [Scribery](https://github.com/Scribery) 
+ * [Scribery](https://github.com/Scribery)
+
+This project is based on the [Cockpit Starter Kit](https://github.com/cockpit-project/starter-kit).
+See [Starter Kit Intro](http://cockpit-project.org/blog/cockpit-starter-kit.html) for details.
 
 # Getting and building the source
 
@@ -30,15 +33,17 @@ make
 
 # Installing
 
-`make install` compiles and installs the package in `/usr/share/cockpit/`. The
+`make install` compiles and installs the package in `/usr/local/share/cockpit/`. The
 convenience targets `srpm` and `rpm` build the source and binary rpms,
-respectively. Both of these make use of the `dist-gzip` target, which is used
+respectively. Both of these make use of the `dist` target, which is used
 to generate the distribution tarball. In `production` mode, source files are
 automatically minified and compressed. Set `NODE_ENV=production` if you want to
 duplicate this behavior.
 
 For development, you usually want to run your module straight out of the git
-tree. To do that, link that to the location were `cockpit-bridge` looks for packages:
+tree. To do that, run `make devel-install`, which links your checkout to the
+location were cockpit-bridge looks for packages. If you prefer to do
+this manually:
 
 ```
 mkdir -p ~/.local/share/cockpit
@@ -48,12 +53,39 @@ ln -s `pwd`/dist ~/.local/share/cockpit/session-recording
 After changing the code and running `make` again, reload the Cockpit page in
 your browser.
 
+You can also use
+[watch mode](https://esbuild.github.io/api/#watch) to
+automatically update the bundle on every code change with
+
+    $ npm run watch
+
+or
+
+    $ make watch
+
+When developing against a virtual machine, watch mode can also automatically upload
+the code changes by setting the `RSYNC` environment variable to
+the remote hostname.
+
+    $ RSYNC=c make watch
+
+When developing against a remote host as a normal user, `RSYNC_DEVEL` can be
+set to upload code changes to `~/.local/share/cockpit/` instead of
+`/usr/local`.
+
+    $ RSYNC_DEVEL=example.com make watch
+
+To "uninstall" the locally installed version, run `make devel-uninstall`, or
+remove manually the symlink:
+
+    rm ~/.local/share/cockpit/starter-kit
+
 # Running eslint
 
 Cockpit Starter Kit uses [ESLint](https://eslint.org/) to automatically check
-JavaScript code style in `.jsx` and `.es6` files.
+JavaScript code style in `.js` and `.jsx` files.
 
-The linter is executed within every build as a webpack preloader.
+eslint is executed within every build.
 
 For developer convenience, the ESLint can be started explicitly by:
 
@@ -65,6 +97,49 @@ Violations of some rules can be fixed automatically by:
 
 Rules configuration can be found in the `.eslintrc.json` file.
 
-# Credits
+## Running stylelint
 
-Cockpit-session-recording is based on [starter-kit](http://cockpit-project.org/blog/cockpit-starter-kit.html).
+Cockpit uses [Stylelint](https://stylelint.io/) to automatically check CSS code
+style in `.css` and `scss` files.
+
+styleint is executed within every build.
+
+For developer convenience, the Stylelint can be started explicitly by:
+
+    $ npm run stylelint
+
+Violations of some rules can be fixed automatically by:
+
+    $ npm run stylelint:fix
+
+Rules configuration can be found in the `.stylelintrc.json` file.
+
+During fast iterative development, you can also choose to not run eslint/stylelint.
+This speeds up the build and avoids build failures due to e. g. ill-formatted
+css or other issues:
+
+    $ make LINT=0
+
+# Running tests locally
+
+Run `make check` to build an RPM, install it into a standard Cockpit test VM
+(centos-8-stream by default), and run the test/check-application integration test on
+it. This uses Cockpit's Chrome DevTools Protocol based browser tests, through a
+Python API abstraction. Note that this API is not guaranteed to be stable, so
+if you run into failures and don't want to adjust tests, consider checking out
+Cockpit's test/common from a tag instead of main (see the `test/common`
+target in `Makefile`).
+
+After the test VM is prepared, you can manually run the test without rebuilding
+the VM, possibly with extra options for tracing and halting on test failures
+(for interactive debugging):
+
+    TEST_OS=centos-8-stream test/check-application -tvs
+
+It is possible to setup the test environment without running the tests:
+
+    TEST_OS=centos-8-stream make prepare-check
+
+You can also run the test against a different Cockpit image, for example:
+
+    TEST_OS=fedora-34 make check