The skill assumed port 4000, but config/dev.exs serves on 8056 (and honours
$PORT), so a fresh demo run failed its liveness check and every rodney URL
pointed at the wrong port.
- demo skill: resolve DEMO_PORT from the app config with
`mix run --no-start -e 'Application.get_env(:firehose,
FirehoseWeb.Endpoint)[:http][:port]'` (Endpoint.config/1 raises without a
started endpoint), derive $DEMO_BASE_URL from it, start the server on that
port from app/, and use $DEMO_BASE_URL in every rodney example. The skill
also points at .tmp/phx-demo.log and names the assets/node_modules
highlight.js failure as a diagnosable cause.
- app/Makefile: new `assets` target that runs `npm install` only when
node_modules/.package-lock.json is missing, and `deps` now depends on it.
A fresh clone gets a working JS bundle from `make deps`/`make test`; later
runs never touch the network, so offline runs keep working.
Verified: guard skips with node_modules present and installs after moving it
aside; the skill's DEMO_PORT command prints 8056 and follows PORT=9999;
make check and make test (179 + 162) green.
- Install highlight.js via npm with 8 language definitions
- SourceViewer hook applies syntax highlighting on mount/update
- Atom One Dark theme for dark mode, Atom One Light for light mode
- Add hooks directory, package.json, and package-lock.json
- Add demo document and screenshots
- Add rodney-docker.md documentation
- Ignore .rodney/ chrome data directory
And particular for this project. I am now reading more markdown, making
smaller steps. So the installation instructions went to the README.
Hmm. having just written about init scripts, the installation may be
best moved to an init script in the skill directory.
Willem van den Ende
mostalive