Commit

91d517f

@dtinth Done (69db93a, local). Slight change of plan: no repacking needed. The browser assets already ship as notes-frontend release tarballs, so notes build downloads the pinned @notes/client + @notes/compiler tgz once, caches them in ~/.cache/notes, and copies compiler/,…
Yes please. It's already in ghq. Access to both repos granted. For notes-frontend, since we will not be making any interface change, you may make changes in a PR to main directly and automatically merge when builds pass.
I took a look. I think that was a good reason for using a development build because when there is a build failure, the stack trace is readable. Is the dev notice suppressable without hijacking console?
@dtinth Yes, without hijacking console. Only the esm-browser build prints that notice. The esm-bundler build has the same dev mode when NODE_ENV is "development", and no notice. PR #2 updated: alias to vue.runtime.esm-bundler.js and define NODE_ENV=development. Same [Vue warn]…
GitHubUse Vue's production build in the compiler by dtinth-claw[bot] · Pull Request #2 · dtinth/notes-frontendThe compiler aliased vue to vue.runtime.esm-browser.js, the dev build, which prints "You are running a development build of Vue" whenever it loads. This shows up every time the compiler r...
@dtinth Main build passed, release v0.0.261020163032 is out. Bumped it on next (local), rebuilt dist/notes.js, and a clean-dir run builds the example site with no Vue notice.
I am thinking about deployment and start doubting my own decisions. With Dokploy, deploying a new version of the server is just a matter of pushing to the repo. Dokploy also allows bind mount, so I can bind mount the vault into the server container. Only uid needs to match. What…
I think it's better. It keeps what mattered in Q1 (the vault stays a plain dir on the host, so Claude Code still works in it bare) and drops the part I liked least: building a release pipeline just to deploy. What changes: - Q25: no bundled-JS release needed for the server. A…
@dtinth Updated docs/SPEC.md for Dokploy + bind-mounted vault, with the CLI as a thin API client (f16dad0, local). Still waiting on a yes to push next and start on legacy parity.
On it: plan/apply against Supabase, behind an interface with an in-memory fake and tests. No live Supabase access here, so I will test against the fake and leave a read-only notes plan for you to run against the real one.