Making test-functions strict required some test adjustments where we
incorrectly expected an number while we receive in fact a string. As
getAttribute() returns either a string or null.
This plugin assumes that the 'po' directory is located at `$SRCDIR/po`
or `./po` if `$SRCDIR` is unset. That conflicts with our desire to be
able to run `build.js` from other directories and is also a little bit
"evil" in terms of hardcoding information about project layout.
Add an optional `podir` option to the plugin which should be set to the
`po/` path. Set it from `build.js` for Cockpit itself. For other users
of the plugin, we preserve the fallback of using `$SRCDIR/po` or `./po`
so that we don't break them on the next cockpitlib upgrade. The
expectation is that everyone will migrate to providing the `podir`
option, however.
Add a -o option (default to `.`) for where to send the output. It will
still be split into `dist/` and `qunit/` subdirectories, but relative to
the given path instead of assuming it goes in the cwd.
Make sure we send `metafile.json` and `runtime-npm-modules.txt` to the
output directory as well.
Between `build.js` and `file.js` we determine the location of `pkg` (and
various tools that we need to invoke) in one of two ways, neither of
them particularly good:
- they're assumed to be relative to '.', which only works if ./build.js
is invoked from the automake srcdir. That happens to be the case
when pkg/Makefile.am does the invocation (it does a 'cd' first) but
it breaks if you try to run build.js manually from a different
directory.
- redundantly, if `$SRCDIR` is set, this will be used in some (but not
all) places
Let's standardize on looking at `import.meta.dirname`. This is how node
resolves imports, so it's pretty much guaranteed to be correct (or else
the script itself wouldn't be running in the first place). This is
an absolute pathname derived from argv[1] as passed to node (ie:
build.js itself).
For the qunit plugin, `import.meta.dirname` is the path of the plugin
itself, which makes it perfect for finding the `.template.html.in` file
located immediately adjacent to itself, saving some path gymnastics.
During our computation to create `runtime-npm-modules.txt` we need to be
careful: pathnames are based on `import.meta.dirname` now and are
therefore always absolute: we need to adjust our logic for finding paths
starting with `node_modules` to consider the relative pathname.
Stop hardcoding 'dist/' all over the place. We already do it once in
the esbuild configuration blob, and that's enough. The other places
(and particularly the plugins) should be reading it from there.
For the qunit plugin, remove a hardcoded instance of 'qunit/'.
During builds remove RH icons from being rendered as they take up space
on the DOM tree without being rendered. Until PF makes the RH icons
default this needs to be done to reduce the import size of each icon by
more than 50%.
Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
Patternfly v6 uses Sass if-functions which has been deprecated in favor
of pure CSS if-functions. However, we need to wait for Patternfly to
move to this and can't do much ourselves.
Ignoring the warnings produced is not super ideal as it catches more
than just Patternfly, but given that we don't use Sass if-functions we
should be fine.
Related-to: https://github.com/patternfly/patternfly/issues/8077
Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
We don't want to ship qunit in our release -node tarballs, and running
them during distribution package build is also a tad too expensive. So
check if `qunit` node module is available, and skip building qunit/ if
not.
When a standard import from node_modules/ fails, use `node`'s
`require()` resolution to find the path to the installed distribution
esbuild package. With that, the package can be built on Debian with just
the `tools/node-modules runtime-tar` modules (i.e. runtime dependencies
minus binary eslint).
Ported from https://github.com/cockpit-project/cockpit-files/commit/c9cb61d9393d46d4e
Our package.json's `dependencies` has transitive/optional dependencies
which don't actually end up in the bundle, e.g. `argparse`,
`attr-accept`, or `js-tokens`; or `react-dropzone` which is a
`@patternfly/react-table` dependency, but not actually used in
cockpit.
The next commit will aggravate this further.
So make the computation of the `Provides: bundled(npm(..))` lines more
precise: Ask esbuild about which modules it actually included, which it
tells us via the "metafile". Change build.js to always output that (drop
the `--metafile` option), compute a ./runtime-npm-modules.txt list, and
use that to build the spec file.
Ported from https://github.com/cockpit-project/cockpit-files/commit/e15a518fddad1
The only significant thing in that custom plugin was the scss hacking.
But that is now obsolete:
* We haven't built and shipped patternfly.woff in cockpit-ws in a long
time, so the `patternfly-icons-fake-path` thing has no effect. We can
just use PatternFly's default.
* Our patternfly-6-cockpit.scss already sets our font path through a
variable, so that text transform was a no-op.
Without that, build.js can use the upstream esbuild-sass-plugin
directly.
That has a number of npm dependencies, not packaged in distros, and
annoyingly silently ignores nonexistent files.
Doing this with `fs.copyFileSync()` is easy as well, so use that
directly. The only snag is that we need to resolve the globs for the
fonts ourselves.
We never minify the qunit output, regardless of our devel/production
setting, so let's also unconditionally emit sourcemaps there as well.
This will be useful for an upcoming code coverage feature for QUnit
tests.
This will collect coverage data from the test runs and write .lcov files
into `lcov/` with names like `qunit-base1-test-fsinfo-html.info.gz`.
Nothing is done with these files yet, but you can manually inspect them
using `lcov`.
I was playing around a bit with deno, and it's a good deal stricter
about imports.
- make sure we don't implicitly use node modules without imports (like
`process.env`)
- make sure we import node modules with their `node:` prefixed names
- minor opportunistic cleanups around quotes and sorting
With these fixes, it's possible to say:
deno run --allow-all --unstable-byonm build.js
Rename qunit-tests.js to .ts and stop hanging our functions on the main
QUnit object (which isn't typesafe). We can just export them from our
module. Adjust the users accordingly.
Add explicit file extensions to the list of tests in files.js (removing
the hardcoded '.js' from build.js) and add our first .ts case.
This new case tests that `cockpit.assert()` works properly in the
positive and negative cases and also verifies that it can be used for
type narrowing (otherwise tsc would complain).
Similar to what commit c9ac6736b3 did for stylelint, move
ESLint to static code checks as well. It already runs from there (and
actually correctly since the previous commit).
stylelint 16 causes a deadlock/crash in esbuild [1]. There's no movement
on that issue, and we want stylelint 16 to be able to support the
Browser Baseline 2023.
So let's give up, and untangle stylelint from esbuild. We can just as
well call it from our static code checks. The main developer regression
is that the feedback cycle is faster in build.js watch mode than calling
test/static-code, but these days with IDE integration (like ALE) that
should hopefully not matter that much.
As we use `git ls-files` now, this also starts to cover files in doc/
and test/. Ignore the former for now, let's fix these separately.
[1] https://github.com/evanw/esbuild/issues/3542
starter-kit and derivatives don't understand the build.js `-r` option,
only the environment variable. So properly handle the latter, and update
the documentation to use the env variable, to get a common workflow for
all our projects.
Also fix the destination path, the rsync plugin moved to
/usr/local/share/cockpit some time ago.
Patternfly-react is in freeze right now, essentially till June when v5
is first released. This is a super hacky work around - but better than
having UI regressions.
This can be undone once patternfly with
https://github.com/patternfly/patternfly-react/pull/8864 is released.
We don't need the `$ESLINT`/`$STYLELINT` env variables any more to
coordinate between build.js and webpack-config.js, as everything is in
build.js now. Update HACKING.md accordingly.
Implement our own watch mode due to the deficiencies of esbuild's [1].
This is similar to podman's [2], but with recursive watching.
Because the approach for redefining breakpoints changed, update pixel
tests for the spacing noise.
Co-Authored-By: Martin Pitt <mpitt@redhat.com>
Fixes#17629
[1] https://github.com/evanw/esbuild/issues/1204#issuecomment-1482909251
[2] https://github.com/cockpit-project/cockpit-podman/pull/1243
This is our primary and only interaction point with building bundles, so it
should be in the top-level directory. Also, we are going to switch to esbuild
soon, so naming it "webpack" will be confusing. Move it to ./build.js like
cockpit-podman already did.
Keep tools/webpack-{make.js,watch} as a shell shim for a little while, which
points to the new tool and the documentation.
