[arthurfiorette]

Closes #3.

With version empty (the new default), the action reads the devlanes version from the project's lockfile, else from an exact version in package.json, else uses 0.7.0. The new version-source output and a log line say which: input, the file's path relative to the workspace, or default.

Changes

• src/detect.ts: one pure parser per format (pnpmLock, npmLock, yarnLock, bunLock, pythonLock for uv and poetry, packageJson), fromPep440, the folder walk (pinnedVersion, with injected exists/readFile/warn) and resolveVersion for the precedence.
• src/inputs.ts: version('') returns '', which main.ts takes as "detect". releasePattern is exported so a detected version goes through the same format and minimum checks as an explicit one.
• src/main.ts: resolves the version before installing and sets version-source. post.ts is unchanged.
• action.yml: version defaults to "", new version-source output.
• README: the precedence, the files and version-source under "Choosing the devlanes version", plus the inputs and outputs tables.
• CI: a lockfile job over test/fixtures/lockfile-pnpm and test/fixtures/lockfile-uv (both generated by pnpm and uv, pinning 0.7.0) runs command: install without version and checks version and version-source. The other jobs keep version: ${{ env.DEVLANES_TEST_VERSION }}; this repo's root pnpm-lock.yaml and package.json name no devlanes, so they still get 0.7.0, and a unit test guards that.

Decisions

• TOML: smol-toml 1.9.1 (BSD-3-Clause, no dependencies) instead of a line reader, so a broken uv.lock or poetry.lock gets the "cannot be parsed" warning instead of silently not matching. It adds about 20 kB to dist/main.js.
• pnpm lockfiles can hold several YAML documents. pnpm 12 writes its own install (packageManagerDependencies) as a document before the project's, as this repo's lockfile does, so the parser reads every document. yaml.parse would have thrown on those.
• pnpm and npm read the importer (or <folder>/node_modules/devlanes) of the working directory first, then those of the folders above it up to the lockfile's, since Node resolves devlanes from parent folders too. npm's own copy in a workspace covers a version that conflicts with the hoisted one.
• Files are checked per folder in the issue's table order, with package.json last. A nearer folder's exact package.json therefore beats a lockfile further up.
• For an exact package.json, version-source is the file's path relative to the workspace, the same as for lockfiles (package.json at the root, apps/web/package.json in a subfolder).
• A detected value that is not a release (such as link:../devlanes or a PEP 440 .dev1) gets a warning and the search goes on, the same as a file that cannot be parsed. Only a release older than 0.7.0 fails the step.
• PEP 440 inverse: rcN/aN/bN map to -rc.N/-alpha.N/-beta.N, and rc0 maps to a bare -rc, matching pep440 in packaging/pypi/build.py.
• pnpm add rewrote the root pnpm-lock.yaml in pnpm's own style, and pnpm lint-fix (Biome) put it back in the committed style, so the lockfile diff is just the new dependency.

Verification

• pnpm lint-ci, pnpm test-types, pnpm test (75 tests) and pnpm build pass locally, and dist/ is rebuilt.
• I ran the bundled dist/main.js against a workspace whose uv.lock pins 0.6.1. It fails with uv.lock pins devlanes 0.6.1, which is too old for this action; use 0.7.0 or later or set version.
• Not verified locally: the e2e jobs and the new lockfile job, which need CI.

Releasing v0.2.0 and moving v0 are left to the maintainer.

[mira-arthur]

Mira PR Walkthrough

When version is left empty (the new default), the action now detects the devlanes version from the project's lockfile (pnpm, npm, yarn, bun, uv, poetry), then from an exact version in package.json, and finally falls back to 0.7.0. A new version-source output and a log line report where the version came from (input, a workspace-relative file path, or default). Detected versions go through the same release-format and minimum-version checks as an explicit input. Note: the metadata shows only the CI workflow file (+1 line), so the rest is described from the PR description.

Confidence: 3/5   ◉◉◉○○   Likely fine, limited visibility

• The PR description is thorough and local checks pass, but only the one-line CI change was visible in the metadata, and the e2e and new lockfile CI jobs were not run locally.

1 file reviewed · 1 unresolved thread

---

Comment @mira-arthur help to get the list of available commands and usage tips.

[mira-arthur]

Mira Review Summary

The new lockfile e2e job in .github/workflows/ci.yml (line 339) is missing from the CI passed gate's needs, so its failure would not block merging. Adding it to that list would make the job a required check.

Key Issues

	Issue	Location
🔴	The new lockfile e2e job is not listed in the CI passed gate's needs, so its failure would not block merging.	.github/workflows/ci.yml:339