Add @atlas/blueapi and @atlas/blueapi-query packages#17
Conversation
douglaswinter
requested review from
EmsArnold,
VictoriaBeilsten-Edmands and
noemifrisina
and removed request for
EmsArnold,
VictoriaBeilsten-Edmands and
noemifrisina
Just linting for ViSR - still need to sort out consistent linting for all apps and packages.
To remove the expectation of prebuilt dist/ folders, we can use composite projects and references. https://www.typescriptlang.org/docs/handbook/project-references.html In this setup: 1) each internal TS package declares itself as composite: "compilerOptions": { "composite": true } 2) each dependent package lists its dependencies as references: "references": [{ "path" : "../dependency" }] 3) each package is built with tsc -b
noEmit should not be in root config; only app configs should declare it
douglaswinter
force-pushed
the
dw/blueapi_package
branch
from
e11e3c7 to
4d8f194
Compare
|
Currently this requires explicitly running a build task, but running |
This commit migrates from a library-style, artifact-driven model (TS project references + tsc -b + dist outputs) to a source-first model: - internal packages export TypeScript source directly - Vite/Vitest own all runtime transformation - TypeScript is used purely for type-checking - CI check added - no build artifacts (dist, .d.ts, .js) are produced inside packages. This simplifies the mental model since no build graph between internal packages is required, and no prebuild step is needed for dev or test. A caveat: Vitest does not immediately start inside vite; it first starts under node, then loads config, initialises vite, finally running tests. For that reason, vitest-conf config is now declared as pure JS, not TS. This also requires explicit declaration files, an inconvenience of source-first.
Changed now by switching to a source-first architecture, where internal packages export TS source code directly. No need for building when running dev. |
EmsArnold
left a comment
EmsArnold
left a comment
There was a problem hiding this comment.
A few variables which may need to be optional, but otherwise functions well and looks good.
|
|
||
| /** Any metadata to apply to all runs within this task */ | ||
| metadata: object; | ||
| } |
There was a problem hiding this comment.
Do params and metadata need to be optional in this case?
There was a problem hiding this comment.
This is what blueapi returns, and I believe metadata is always there, and if no params were specified with the task you get an empty object. If that's true, neither are optional.
packages/blueapi/src/tasks.ts
Outdated
| name: string; | ||
|
|
||
| /** Values for parameters to plan, if any */ | ||
| params: object; |
There was a problem hiding this comment.
Should params be optional here?
There was a problem hiding this comment.
Yes, thank you!
2 participants
Introducing two very light packages.
@atlas/blueapi: axios blueapi queries. Can be used as is, or through
@atlas/blueapi-query: tanstack react query wrappers for the above, exposing hooks such as usePlans(), etc.