document-schema.js now publishes decompose, flattenPackage, factorStyles, assemblePackage, ConstructMarkerImbalanceError, and the PackageChildren type from its own barrel (ExaDev/document-schema.js#27) -- the same structural transform documents.js currently keeps as its own copy at src/convert/{decompose,flatten,factor-styles,canonicalise}.ts.
Once document-schema.js publishes a release containing that transform (>=4.3.0), documents.js should:
- Bump the
document-schema.js dependency via the normal sibling-dependency-update flow (not a manual version edit).
- Import
decompose/flattenPackage/factorStyles/assemblePackage/ConstructMarkerImbalanceError/PackageChildren from document-schema.js rather than src/convert/.
- Delete
src/convert/decompose.ts, src/convert/flatten.ts, src/convert/factor-styles.ts, and src/convert/canonicalise.ts, along with their dedicated test files, once the relocated implementation is confirmed to cover the same ground.
- Keep
bijection.test.ts's real-format corpus (readers, editors, onDocument captures) running against the relocated implementation rather than dropping it -- that corpus is exactly what document-schema.js's own copy of the law suite cannot cover, since importing it there would invert the dependency direction the relocation exists to protect. This is the run that actually proves the relocation broke nothing against real documents, not just the hand-built corpus the relocated suite ships with.
Until this lands, src/convert/'s copies and document-schema.js's relocated copies are free to drift from each other.
document-schema.js now publishes
decompose,flattenPackage,factorStyles,assemblePackage,ConstructMarkerImbalanceError, and thePackageChildrentype from its own barrel (ExaDev/document-schema.js#27) -- the same structural transform documents.js currently keeps as its own copy atsrc/convert/{decompose,flatten,factor-styles,canonicalise}.ts.Once document-schema.js publishes a release containing that transform (
>=4.3.0), documents.js should:document-schema.jsdependency via the normal sibling-dependency-update flow (not a manual version edit).decompose/flattenPackage/factorStyles/assemblePackage/ConstructMarkerImbalanceError/PackageChildrenfromdocument-schema.jsrather thansrc/convert/.src/convert/decompose.ts,src/convert/flatten.ts,src/convert/factor-styles.ts, andsrc/convert/canonicalise.ts, along with their dedicated test files, once the relocated implementation is confirmed to cover the same ground.bijection.test.ts's real-format corpus (readers, editors,onDocumentcaptures) running against the relocated implementation rather than dropping it -- that corpus is exactly what document-schema.js's own copy of the law suite cannot cover, since importing it there would invert the dependency direction the relocation exists to protect. This is the run that actually proves the relocation broke nothing against real documents, not just the hand-built corpus the relocated suite ships with.Until this lands,
src/convert/'s copies and document-schema.js's relocated copies are free to drift from each other.