* Stop importing cockpit's base1/patternfly.css
This is deprecated API and will be dropped at some point, in favor
of projects shipping their own CSS.
Install and import the styles from PF4 now.
* Use webpack based string replacement for removing the font-face rules from PF4
Doing the seddery in Makefile breaks `npm run build`, webpack watching,
and is generally brittle.
Do the font replacement hacking with `string-replace-loader`, which fits into webpack much more nicely.
There is still some potential simplification by not duplicating the
entire scss loader chain.
Co-authored-by: Martin Pitt <martin@piware.de>
Closes#315
Similar to what cockpit-composer does. This is rather simplistic, but
does fine until we need more complex scenarios.
Also use plain shell in test/run, there are no bashisms.
Closes#291
Avoid phony dependencies, as they break timestamp comparison and thus
always cause rebuilding of the tarball, rpm, and (the very expensive) VM
for each `make check`, even if only the tests (or nothing at all)
changed.
Use `rpmspec` to predict the name of the built rpm. Use the .spec.in
file directly, as we can't depend on the generated .spec file in the
variable definition.
Closes#290
Use `%{VERSION}` as version macro instead of `@VERSION@`, so that the
.spec.in file is syntactically a correct spec file that can be parsed
with `rpmspec`.
We don't need the full cockpit metapackage with cockpit-docker, etc.
The starter-kit RPM will already pull in cockpit-system, so we just need
cockpit-ws.
It looks like Webpack is deprecating extract-text-webpack-plugin in favor of
mini-css-extract-plugin.
Discussion can be found here: webpack-contrib/extract-text-webpack-plugin#731
Closes#271
These make components with simple state (only a few variables) easier to
read and maintain. See https://reactjs.org/docs/hooks-intro.html for
details. Hook are available since React 16.8, and we already depend on 16.10.
We can't use hooks in our actual code, as our only `Application`
component needs a constructor. But this enables the ESLint plugin to
guide developers to the right path if they use hooks.
Closes#239
* If `$COCKPIT_BOTS_REF` is set, check out that bots version instead of
master.
* Use git cache in $XDG_CACHE_HOME if available. Our CI uses that to
save downloads, and it does not get in the way for local developers.
* Stop making "bots" a phony target, and drop the now unnecessary
`[ -d bots ]` check.
Closes#233
Commit 95b2aff0 was a thinko -- for our CI we *don't* want our test to
clobber a pre-existing bots/ checkout, as we often use this to run tests
against an updated image or to validate a changes to the bots project.
On developer machines, bots may also be a symlink to an actual bots
directory in development, so don't clobber that.
Closes#232
This is meant to only control webpack. But `npm install` skips
installing `devDependencies` under `NODE_ENV=production`, which breaks
the package build. So always unset it for npm.
This fixes `NODE_ENV=production make` in a clean tree.
`npm install` does not update/touch an already existing
package-lock.json. Thus after
make
touch package.json
make
a subsequent `make` would still run `npm install`. To fix this, remove
package-lock.json before `npm install`, so that (1) package-lock.json
always gets touched and thus the make rule actually works, and (2)
during development we always get up to date packages (we only really
want the "locking" behaviour for building from release tarballs).
Also run `npm prune` so that switching between git trees with
added/removed modules works correctly.
Closes#223
