Robert/js modules in document support#23
Conversation
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
…lder Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
Co-authored-by: piotr-blue <piotr-blue@users.noreply.github.com>
…minism checks - move quickjs-runtime specs from src/lib to src/test - group runtime tests by execution profile - migrate gas goldens, dv parity, host gas, binary parity, and module-pack parity into libs/test-harness - trim quickjs-native-harness legacy script to native-only CLI/report coverage - run both new and legacy native harness suites in GitHub Actions - add missing determinism coverage for compat-regexp-v1, replay stability, and init boundary checks
- fix prettier formatting in runtime, test-harness, native harness, and consumer app files - move vitest to quickjs-runtime dependencies for nx dependency checks - clean up helper/test files to satisfy eslint and prettier
Remove compat-regexp-v1 from the public execution profile registry, runtime validation, docs, and tests. RegExp-compatible coverage now uses compat-general-v1, which remains the supported profile for deterministic RegExp behavior. Also delete the dedicated compat-regexp-v1 runtime spec and update related type unions and profile lists so artifacts only accept the remaining public profiles.
Introduce @blue-quickjs/blue-documents for building and validating BlueQuickjs JavaScript document workflows. The library supports JavaScript library source documents, npm-origin library imports, import locks, environment contract merging, step artifact builds, document inspection, canonical JSON hashing, and source integrity checks. Wire the new document workflows into blue-quickjs CLI with commands for mporting npm libraries, building library artifacts, creating import locks, building step documents into ProgramArtifact.v2, and inspecting Blue documents. Add Vitest coverage for library artifact creation, import lock validation, contract merging, step artifact generation from locked libraries, and local npm package imports.
Add an end-to-end example showing how to import a pinned npm package into a Blue document, lock it through a generated library artifact, process the user document into a ProgramArtifact.v2, and run it with the CLI. Add a create-step-document CLI command that emits JSON or YAML user documents from an entry file plus a library artifact, including import lock creation and output directory creation. Add YAML support for the CLI/example flow and update TypeScript project references needed by the affected workspace packages.
Introduce runtime APIs for building ModulePack.v1 artifacts directly from source maps and module source entries. The builder normalizes specifiers and line endings, resolves reachable static imports, supports explicit bare import aliases, computes canonical graph hashes, and reports deterministic compatibility diagnostics before evaluation. Extract module-pack graph hashing into a shared runtime helper and export the new builder, hash utilities, and validateModulePack API. Add acorn for module parsing. Fix module export lookup so an explicitly exported undefined value is not treated as a missing export, and cover the new builder, hash, validation, and undefined-export behavior with tests.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3b204cf060
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const packageName = parts[0] ?? specifier; | ||
| const rest = parts.slice(1); |
There was a problem hiding this comment.
Reject non-package import specifiers before materialization
parsePackageImportSpecifier accepts any string and uses the first path segment as packageName without validation, so specifiers like ../lib or ./x produce packageName values such as .. or .. In materializeModulePackAsPackage, those names are joined into node_modules/<packageName>, which can escape or collapse the intended package directory and write files in unintended locations, breaking builds and allowing path traversal through crafted import-lock specifiers.
Useful? React with 👍 / 👎.
| const exports: Record<string, string> = { | ||
| '.': `./${entryPath}`, | ||
| }; | ||
| if (options.exportSubpath) { | ||
| exports[options.exportSubpath] = `./${entryPath}`; |
There was a problem hiding this comment.
Preserve existing exports when materializing same package twice
Each call to materializeModulePackAsPackage rewrites package.json with a fresh exports object containing only . plus the current exportSubpath. If a step imports multiple subpaths from the same package (for example pkg/a and pkg/b), the second write drops the first subpath export and later resolution of that import fails. The function should merge with existing exports for the package root instead of replacing them on every call.
Useful? React with 👍 / 👎.
| if (abiId === 'Host.v2') { | ||
| return HOST_V2_HASH; | ||
| } | ||
| return HOST_V1_HASH; |
There was a problem hiding this comment.
Error on unknown ABI IDs when selecting manifest hash
abiManifestHashFor falls back to HOST_V1_HASH for every ABI ID other than Host.v2, so unsupported IDs silently get a Host.v1 manifest hash. That can emit internally inconsistent program artifacts (e.g., abiId: "Foo.v3" paired with Host.v1 hash) instead of failing fast, which makes downstream evaluation and verification behavior ambiguous.
Useful? React with 👍 / 👎.
No description provided.