| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
I've been doing this by hand anyways, and this makes it a _ton_ less tedious to maintain. I think it looks nice.
This does, however, require nightly - for formatting only.
|
| |
|
|
|
|
| |
later on) when checking validity of Rust code.
I inadvertantly broke a test and my pre-commit hook, which runs `tools/check-lint`, didn't catch it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To reproduce:
* Make any change (even just `touch`) to a file in `ui`.
* Run `tools/run`.
There's a decent chance that the script will fail, with esoteric and variable errors:
```
failed to load config from .../pilcrow/vite.config.js_api(buil...
error when starting dev server:
Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@sveltejs/kit' imported from .../pilcrow/vite.config.js.timestamp-1752608239248-52b6b8965ad28.mjs
```
is one such exmple.
These errors are due to the `npm ci` carried out by `cargo` at build time (see `build.rs`), which deletes and re-creates `node_modules`. Vite and Svelte do not like having `node_modules` deleted out from under them. As `cargo` will rerun `build.rs` any time `ui` changes, this means that `tools/run` effectively requires a complete build _first_, before it can be run.
|
| |
|
|
|
|
| |
The audience for this is developers looking to make changes to Pilcrow, either on the server, on the included client, or via its data model. Most of the material here is drawn from existing documents, but organized somewhat more coherently.
I've left some space for client documentation, though no such documents exist yet.
|
| |
|
|
| |
There isn't a corresponding fix script for this as the lockfiles are rebuilt every time you run a command that resolves dependencies, in either `cargo` or `npm`. Furthermore, `cargo build` (and anything else that runs `build.rs`) will implicitly run `npm install` and update `package-lock.json` in the process.
|
| |
|
|
| |
The new `tools/check-lint` script checks lints across _all_ lintable files - JS (through `eslint`), and Rust (through `clippy` and `cargo check`). It also checks `eslint` against the whole project, not just against what's in the `ui` subdir, which means it now catches lintable issues in various JS config files.
|
| |
|
|
|
|
| |
The new `tools/check-format` script checks _all_ project formatting - JS (through `prettier`), and Rust (through `rustfmt`). It also checks `prettier` against the whole project, not just against what's in the `ui` subdir, which means it now catches formatting issues in various JS config files (like `.prettierrc` itself).
This commit does not include style _fixes_, which means that it does not pass its own `tools/check-format` script. This is intentional, and is intended to make the Git history a bit easier to reason about; a future commit will include format fixes.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I've opted to run with `--coverage` to ensure that we continue exercising coverage support. Hat tip to @wlonk for holding me accountable on this - I had thought coverage was broken, but I was holding it wrong.
Also adjusts the code coverage failure thresholds to match here-and-now reality. I'm not offering a policy thought here, just making sure we
1. use the coverage checking we have, and
2. set standards we are actually achieving.
This was originally part of [another proposal][pr-6]. I've broken it out to make the intent clearer, and to make the proposal easier to get a handle on in isolation from other, related changes. Thanks to @wlonk for their input on this!
[pr-6]: https://codeberg.org/ojacobson/pilcrow/pulls/6
Merges prop/test-tool into main.
|
| | |
| |
| |
| | |
I've opted to run with `--coverage` to ensure that we continue exercising coverage support. Hat tip to @wlonk for holding me accountable on this - I had thought coverage was broken, but I was holding it wrong.
|
| |/
|
|
|
|
| |
Calling through `npm` wasn't adding anything other than complexity, and it made it somewhat harder to follow what tools did what.
I'm also pretty sure `tools/build-ui` was totally unused.
|
| |\ |
|
| | |
| |
| |
| | |
the unified build.
|
| | |
| |
| |
| |
| |
| |
| | |
* It now _always_ runs both the backend and the frontend.
* The frontend is now _always_ exposed on both `localhost` and on the machine's local network interfaces.
The role of running a consolidated server is now handled by `cargo run` (this has been possible since e7d4b6d7ddbcd0128e47476e6cd1d824a1929f3c anyways).
|
| |/
|
|
| |
`test-all` instead of `test` to avoid colliding with a shell builtin.
|
| | |
|
| |\ |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
| |
This includes a change to tools/run that exposes the dev server on my
local network. This change should not make it into the final form of
this branch.
This is so I can use actual for real touch events on my actual for real
phone, hooked up for remote debugging to my computer so I can see
console events etc.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit provides a Docker-based build process for generating `.deb` packages, which can be run in Docker Desktop. I don't love it, but it's the best option I have _right now_ for doing this.
The resulting packages:
* Install `hi` (and `hi-recanonicalize`), in `/usr/bin`.
* Create a user (`hi`) and a data directory (`/var/lib/hi`).
* Create and start a systemd service unit for `hi`.
Packages are built for arm64 and amd64 (aka x86_64).
|
| | |
| |
| |
| | |
This allows skipping the `target/ui` rebuild if the UI has not changed, which has otherwise been a bit of a source of drag on my development speed.
|
| |/
|
|
|
|
| |
Mobile-friendly anyway. Thanks to
[Miriam](https://www.miriamsuzanne.com/) for the CSS that enables a
sliding menu on mobile size, constant menu on larger.
|
| |
|
|
|
|
| |
Having the whole API in a single file was starting to feel very cramped and constraining. This rewrite breaks it out into sections; as a side effect, the docs are now about 2.5x as long as they were, as the rewrite allows more space for each idea without crowding the page.
The docs are best read by running `tools/docs-api`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
