Closed stephenh closed 2 years ago
Oh neat! This is better than what I was thinking which was just a .ts file with an export
but you'd have to export it with an as TYPE
to get the typing.
Yeah, @KoltonG just talking out loud, what I'm unsure of is "who parses the *.ts
file"?
I.e. if we do:
npm run truss-codegen
And that runs our node_modules/@homebound-beam/truss/dist/index.js
file, and we do require("./truss-config.ts")
to pull in the project's TS file... how will that be kosher with node?
A simple answer is to just have ts-node already running / instrumenting the require
hook, which is how our truss/
-via-subdirectory setup works, but that's b/c it's the callers responsibility to "run ts-node
first".
For whatever reason, I was nervous about auto-installing ts-node on behalf of the user, i.e. what if they need to have an older/newer version of ts-node/or are using swc/node ... but actually I'm probably overthinking all of this...
And we could just do:
require("ts-node/register/transpile-only")
Before doing require("./truss-config.ts")
...
:tada: This issue has been resolved in version 1.111.0 :tada:
The release is available on:
v1.111.0
Your semantic-release bot :package::rocket:
Per @KoltonG 's suggestion, it would not be terrible to move to a jest/prettier/etc.-style setup where instead of
truss/index.ts
directly calling agenerate
method, it instead exporting a config object, i.e.:Where
defineConfig
is a way of providing defaults + type checking, and is whatvite.config.ts
uses.At the same time, we could move
truss
into a top-leveldevDependency
and atruss-codegen
script instead of a dedicatedtruss/
directory. The original rationale of being super-isolated intruss/
(i.e. its ownpackage.json
) plus potentially having many separate files i.e.truss/palette.ts
,truss/index.ts
, are still potentially valid, but in reality probably not that big of a deal, given the inertia / default convention of top-level config file.