@calcit/procs 0.13.13 → 0.13.14
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/.yarn/install-state.gz
CHANGED
|
Binary file
|
package/README.md
CHANGED
|
@@ -130,6 +130,8 @@ Related examples and workflows:
|
|
|
130
130
|
:dependencies $ {}
|
|
131
131
|
|calcit-lang/memof |0.0.11
|
|
132
132
|
|calcit-lang/lilac |main
|
|
133
|
+
:dev-dependencies $ {}
|
|
134
|
+
|calcit-lang/calcit-test |0.1.0
|
|
133
135
|
```
|
|
134
136
|
|
|
135
137
|
Run `caps` to resolve the recursive dependency graph and install it. Immutable revisions are stored under
|
|
@@ -141,6 +143,10 @@ Published SemVer tags are preferred. Branch refs remain supported for developmen
|
|
|
141
143
|
the resolved commit. When a graph requests several SemVer tags for one repository, the highest requested
|
|
142
144
|
version is selected and reported.
|
|
143
145
|
|
|
146
|
+
Root projects install both `:dependencies` and `:dev-dependencies`. Recursive resolution only follows
|
|
147
|
+
`:dependencies`, so test and maintenance modules declared by a dependency do not leak into consumers.
|
|
148
|
+
Use `caps add --dev <org/repo>@<ref>` and `caps remove --dev <org/repo>` to manage the development group.
|
|
149
|
+
|
|
144
150
|
`:calcit-version` helps with version checks and provides hints in [CI](https://github.com/calcit-lang/setup-cr).
|
|
145
151
|
|
|
146
152
|
To load modules, use `:modules` configuration and the runtime snapshot file `calcit.cirru` (legacy: `compact.cirru`):
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
# Scope development dependencies in recursive resolution
|
|
2
|
+
|
|
3
|
+
## Knowledge points
|
|
4
|
+
|
|
5
|
+
- `deps.cirru` now distinguishes consumer-facing `:dependencies` from root-only
|
|
6
|
+
`:dev-dependencies`.
|
|
7
|
+
- A root project resolves and installs both groups. A materialized dependency module exposes only
|
|
8
|
+
its `:dependencies` to the recursive graph, preventing its tests, examples, documentation tools,
|
|
9
|
+
and maintenance modules from leaking into consumers.
|
|
10
|
+
- The same repository may appear in both root groups only when both declarations use the same ref;
|
|
11
|
+
conflicting refs fail before installation or before `caps add` writes the file.
|
|
12
|
+
- `caps add --dev` and `caps remove --dev` manage development dependencies. `caps outdated` and
|
|
13
|
+
`caps upgrade --all` inspect both root groups and update the declaration in its original group.
|
|
14
|
+
- Upgrade guidance should ask projects to audit dependency intent, move project-only tooling into
|
|
15
|
+
`:dev-dependencies`, and confirm the resulting boundary with `caps tree`.
|
|
16
|
+
- A legacy-project upgrade must be staged: record the old behavior, update `cr`/`caps`, migrate the
|
|
17
|
+
dependency graph and Snapshot, then run every entry through strict preprocessing before tightening
|
|
18
|
+
dynamic dispatch and static debt baselines.
|
|
19
|
+
- `--check-only` is a blocking preprocessing gate, including warnings, but it covers the selected
|
|
20
|
+
entry's reachable path rather than every public definition. `check-types`, `weak-types`, and
|
|
21
|
+
`deprecated` are report commands whose JSON summaries require explicit CI comparison.
|
|
22
|
+
- Type-debt baselines should compare separate categories instead of one total. For coverage, track
|
|
23
|
+
`none` and `none + partial` so progress from none to partial is accepted; track dynamic, nil,
|
|
24
|
+
Optional compatibility, and deprecated calls independently.
|
|
25
|
+
|
|
26
|
+
## Validation
|
|
27
|
+
|
|
28
|
+
- `cargo fmt`
|
|
29
|
+
- `cargo clippy -- -D warnings`
|
|
30
|
+
- `yarn compile`
|
|
31
|
+
- `cargo test`
|
|
32
|
+
- `yarn check-agent-interface`
|
|
33
|
+
- `yarn check-all`
|
|
34
|
+
- `cr docs format-md docs/run/upgrade.md --check`
|
|
35
|
+
- `cr docs check-md docs/run/upgrade.md --entry calcit/test.cirru --failures-only`
|
|
36
|
+
- `cr docs graph check` (with a temporary writable HOME/cache)
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Audit the legacy project upgrade playbook
|
|
2
|
+
|
|
3
|
+
## Findings
|
|
4
|
+
|
|
5
|
+
- An old project cannot safely treat dependency upgrade success as completion. The workflow must
|
|
6
|
+
preserve an old-toolchain behavior baseline and separate tool, dependency, Snapshot, type, and
|
|
7
|
+
behavior changes into reviewable stages.
|
|
8
|
+
- New CLI validation has distinct failure semantics. `--check-only`, examples, Markdown checks, and
|
|
9
|
+
tests are blocking gates; static type/deprecation analysis emits reports that require explicit
|
|
10
|
+
JSON summary comparison in CI.
|
|
11
|
+
- Strict preprocessing must run for every named entry, then run again with `--warn-dyn-method`.
|
|
12
|
+
Entry reachability does not replace tests/examples for public library definitions.
|
|
13
|
+
- Gradual typing needs category-aware baselines for none/not-full coverage, dynamic locations,
|
|
14
|
+
nil/Optional debt, and deprecated calls. A single aggregate can hide category regressions.
|
|
15
|
+
- Snapshot migration must verify which legacy file is authoritative and must not claim that Calcit
|
|
16
|
+
no longer depends on a Snapshot.
|
|
17
|
+
|
|
18
|
+
## Documentation validation
|
|
19
|
+
|
|
20
|
+
- `cr docs format-md docs/run/upgrade.md --check`
|
|
21
|
+
- `cr docs check-md docs/run/upgrade.md --entry calcit/test.cirru --failures-only`
|
|
22
|
+
- `cr docs graph check` with a temporary writable HOME/cache: 22 nodes, 51 edges
|
|
23
|
+
- `git diff --check`
|
package/lib/package.json
CHANGED