Yarn is the better package manager IMO, but npm comes with node and
using it does make the end-user installation experience a little
simpler as a result.
We'll keep the door open for side-by-side support of Postgres in
the background, but due to SQLite's type system quirks we cannot
use the same DDL for both databases, so we would have to maintain
two sets of DDL (schema init and schema migration scripts) at once.
Interested future contributors can shoulder this maintenance burden
if they so choose.
Everything is a scalar value now, and while this does involve more
boilerplate it will also catch type conversion issues like
"1" + 0 === "10" in the future.
This is in preparation for a transition to SQLite, which sadly does
not support array-valued columns (or indeed have much of a type
system in general).
This commit declares and type-checks the following clauses:
* limit().offset() chains on SelectStatement
* onConflict().doUpdate() chains on InsertStatement
We need to flesh out the other possibilities for onConflict() in
particular before all these changes get submitted as an upstream
PR.
This will allow us to cleanly extend these interfaces with
additional clauses understood by Postgres, which we can then chain
without having to redeclare the entire interface.
Wrap everything in a module instead of a namespace. I'm still not
entirely clear on what the distinction is but the forked typings
don't seem to get applied without this change.
This is in preparation for a transition to SQLite. SQLite does have
a similar concept called "attached databases", but it's kind of a
pain to deal with if you're casually browsing a database from the
`sqlite3` CLI so we'll just use some slightly uglier explicitly
namespaced table name identifiers instead.
Hostname is configured from .env now along with everything else.
JSON state storage backend has been abandoned. We might add an
SQLite backend to go with the current Postgres backend at some
point though; SQLite even supports window functions these days.
For some reason initpki doesn't generate a set of certs that are
acceptable to the P-Ras core, even though I never modified it.
Maybe some defaults changed in a recent release of OpenSSL or
something.
Well, to make everybody's life easier let's all just use the same
private keys for everything. It's not like it matters.
PowerOn uses HTTP slightly incorrectly, but other endpoints use
HTTP incorrectly in different ways (or maybe even correctly, who
knows). Scope the current request interceptor to just PowerOn.
