SOF-8032: clean TS - #5
Open
k0stik wants to merge 20 commits into
Open
Conversation
…ake it generic
esse's job/base.json and system/job-extended.json are gone (folded into a
single flat `job` schema); ExtendedJobSchema no longer exists. Point
@mat3ra/esse at the WIP tarball with that change and rework Job to match:
- Add scripts/generate-mixins.ts (mirrors wode's), generating JobSchemaMixin
straight from esse's `job` schema with skipFields for the keys owned by
NamedEntity/Defaultable/etc (_id, slug, systemName, schemaVersion, name,
isDefault, metadata) - replaces the hand-written mixin and its
ExtendedJobSchema-based ConflictingKeys Omit hack. statusTrack, dataset,
_materials/_materialsSet, purged/purgedAt now come through automatically
since esse's `job` schema already merges them.
- Make Job<S extends JobEntity = JobEntity> generic (ade/wode-style), so a
host app (e.g. web-app's upcoming CoreJob) can extend it with a narrower
schema. JobEntity is esse's own JobSchema (not the Omit-restricted mixin
type) plus two client-only fields, material/materials, that hold live
@mat3ra/made instances instead of the persisted _material/_materials
references - as plain instance properties (like _workflow), never
routed through _json: _json only ever holds esse-schema-defined data.
- Drop isEntitySet handling entirely - Job always initializes its workflow
instance now. Entity-set variants get their own class in web-app (same
split as CoreWorkflow/CoreWorkflowSet), not a runtime branch in the
shared base class.
- Point @mat3ra/ide at wip-a02d972 (generic ComputedEntityMixin<C> - see
that repo's SOF-8032 commit) and drop the `compute: EsseJobSchema["compute"]`
own-member override + its TODO in favor of
ComputedEntityMixin<EsseJobSchema["compute"]>.
- Restore render()'s scopeGlobal param; material/materials (and the factory
helper's material param) are typed as wode's OrderedMaterial directly,
no cast at the render() call site.
- setMaterial/setMaterials/setParent no longer need
`as unknown as {getAsEntityReference?}` casts - Material/Job already
extend InMemoryEntity, which has it natively.
- Throughout, prefer the mixin's own this.<field> accessors (this.parent,
this._material, this.workflow, this.dataset, ...) over this._json.<field>.
- Drop the hand-rolled statusTrack/statusCls-adjacent duplicate accessors
now covered by the generated mixin; keep the derived helpers
(statusTrackSorted, submittedTimestamp, ...) guarding against undefined.
- Removed the CJS/ESM interop dance around the WodeWorkflow default import
(`(WodeWorkflowDefault as any).default ?? WodeWorkflowDefault`) - jove's
own Vite-bundled standalone entry does a plain default import of the same
module and calls `new Workflow(json)` directly with no such handling, and
nothing else in wode/jove/job-designer does this anywhere.
Not run through eslint - `eslint` was never added as a devDependency in
this repo (CI itself passes skip-eslint: true for the same reason), so
`lint`/`lint:fix`/the husky pre-commit hook's lint-staged step fail with
ENOENT here regardless of this change; not fixing that dependency gap in
this commit (pulling in @exabyte-io/eslint-config's ~13 peers is a separate,
larger change - same conclusion reached independently for ide).
Verified: `tsc --noEmit` clean, `npm ci` in sync with package-lock.json,
`npm test` 21/21 passing.
…ndler cleanup, no behavior change)
…n now extends InMemoryEntity)
…ge no longer reads owner)
…ed to job schema)
…n split into computedEntityMixin + infrastructureMixin, no source changes needed here)
…l dropped from infrastructureMixin)
…d from job schema)
…hed npm versions These were pinned to stale WIP tarballs left over from before those packages' own work landed on npm - none of them have in-flight changes from this branch's work, so there's no reason to stay on a WIP pin. esse/ide stay on their WIP tarballs (this branch's own active changes); wode was already on a real published version. ade wip-27f6c05 -> 2026.8.18-0 mode wip-02b85be -> 2026.8.18-0 prode wip-52f33d4 -> 2026.8.18-0 standata wip-35eaef7 -> 2026.8.18-0 utils wip-9a19d0d -> 2026.8.18-1 Also includes an incidental fix picked up in the same install/verify pass: Job.toJSON()'s `workflow: this._workflow?.toJSON() as any` no longer needs the cast (and its eslint-disable) - WodeWorkflowType.toJSON()'s return type already satisfies S["workflow"] against the current dependency set. Verified: clean `rm -rf node_modules package-lock.json && npm install`, tsc clean, npm test 21/21, npm run transpile clean.
…ueue optionality now tied to compute's own)
@mat3ra/mode's real npm version pulls in @babel/eslint-parser, whose
eslint peer dependency npm auto-installs under strict peer resolution.
The lockfile had only ever been written with --legacy-peer-deps (which
skips peer installs), so it never recorded eslint's own dependency
tree - causing CI's bare `npm ci` to fail with EUSAGE ("Missing: X
from lock file") on every eslint transitive dep. A plain `npm install`
resolves without conflict and regenerates a lockfile `npm ci` accepts.
Also drops a now-unnecessary `as any` cast on `workflow._json` in
Job.createFromWorkflow.
jode never had eslint wired up (its CI passed skip-eslint: true for this reason). Adds the same eslint/prettier devDependency set wode already uses, fixes the resulting lint errors (for...of loops, require() calls, unused-expression chai assertions, a dead unparseable setup.js), and drops the interface's redundant <S> type parameter - declaration merging between an interface and a class doesn't require matching generics, so it was only there to appease a rule that then had to be disabled for it.
…ase]
Esse's job schema inlines workflow.workflows (sub-workflows share the
parent's schema) as a bare `{ type: "object" }` with no properties, so
json-schema-to-typescript generates it as `{}[]` - unusable. wode's own
WorkflowSchema expresses the real recursive structure, so it replaces
the generated one on JobEntity, same fix web-app's CoreJobSchema already
applies on top of its own (separately-generated, same defect) schema.
…ents JobEntity [release]
Skip `workflow` from the generated jobSchemaMixin (same reason wode's own
Workflow.workflows is hand-written rather than generated: the schema's
recursive workflow.workflows field resolves to a lossy `{}[]`) and add a
real get/set workflow pair typed against wode's WorkflowSchema directly
on the class body, mirroring wode's own Workflow.workflows exactly. This
lets Job<S> genuinely `implements JobEntity` instead of relying on
structural compatibility that the generated mixin couldn't provide.
Also fixes a latent bug in setJobNameBasedOnMaterials: it read
`isMultiMaterial` off the raw workflow JSON (which has no such field -
it's a computed getter on the live Workflow instance), so the check was
always false regardless of the actual workflow. Now reads job._workflow
directly, matching the correct pattern already used a few lines above in
the same file.
…ion [release] setWorkflow assigned via `this.workflow = ...`, which dispatches through whatever `workflow` accessor is active on `this` at runtime. A host subclass that shadows `workflow` to mean the live WodeWorkflow instance (web-app's CoreJob) would route that assignment back into setWorkflow with a plain JSON object mistaken for a WodeWorkflow, corrupting `_workflow` and crashing on `plainObject.toJSON is not a function`. Write to `_json` directly instead, matching the pattern the `workflow` setter itself already uses.
…release] The prior pin (wip-0fdb21e) had been garbage-collected by esse's scheduled stale-tarball cleanup, breaking fresh installs and this repo's own release-wip workflow. Repin to wip-b0bf9ef, a fresh release cut from esse's chore/SOF-8032 branch tip - verified to carry the same job schema fields (dataset, statusTrack, _materials, _materialsSet, isExternal removed) that this package's Job.ts and tests depend on.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.