@exadev/semantic-release-workspace 1.0.2 → 1.0.3

package/README.md

@@ -22,7 +22,7 @@ One orchestrator run, five stages:
 
 When a package releases version `V`, every *not-yet-released-this-run* workspace package that depends on it gets its dependency range updated — and the timing of that update is the least obvious part of the whole design, because getting it wrong is exactly the bug class the documents.js ecosystem's old cross-repo automation hit (the `sibling-dependency-update` heal-job downgrade race: repository state and published manifests disagreeing, then automation "healing" in the wrong direction; see [documents.js#664](https://github.com/ExaDev/documents.js/issues/664)).
 
-The orchestrator's rule: **the moment a package's release completes, each dependent's manifest is rewritten on disk, committed, and pushed — before anything else happens.** A bump commit looks like:
+The orchestrator's rule: **the moment a package's release completes, each dependent's manifest is rewritten on disk, `pnpm-lock.yaml` is regenerated to match, and both are committed together and pushed — before anything else happens.** A bump commit looks like:
 
 ```
 chore(deps): bump @fixture/a to ^1.1.0 in @fixture/b [skip ci]
@@ -31,6 +31,7 @@ chore(deps): bump @fixture/a to ^1.1.0 in @fixture/b [skip ci]
 Why commit immediately, rather than the alternatives:
 
 - **Why commit at all (not just edit the working tree)?** A dependent's semantic-release run analyses *git history*, not the working tree. An uncommitted manifest edit is invisible to its commit analysis, so the dependent could be judged "no changes" and skip a release — leaving a manifest that names a version the registry has, but which the dependent never published, stranded uncommitted in one developer's checkout.
+- **Why regenerate `pnpm-lock.yaml` in the same commit?** `pnpm install --frozen-lockfile` (what CI runs) rejects a tree where the lockfile's recorded specifier for a workspace dependency disagrees with the manifest. Committing the manifest bump without regenerating the lockfile leaves exactly that disagreement, breaking `--frozen-lockfile` installs on the dependent's directory until someone runs `pnpm install` by hand and commits the result — so the lockfile is regenerated and committed alongside the manifest, never as a separate step.
 - **Why before the dependent's own run (not after)?** The dependent's release commit and its published artifact must carry the new range. Bumping after would publish the dependent with a stale range, then mutate the repository afterwards — the repository/published-artifact disagreement this tool exists to prevent.
 - **Why push immediately?** The same crash-consistency discipline semantic-release applies to its own release commits: if the orchestrator dies halfway through the run, everything pushed so far (releases, tags, bump commits) is a consistent prefix, and the next run picks up cleanly from the tags. `[skip ci]` on the bump message stops the push from triggering a *second*, racing release run. The bump commit also carries a machine-parseable trailer alongside its human-readable subject, recording the dependency, its released version, and the new range -- so a fresh run's per-package analysis recognises a bump commit that already exists in history (whether from earlier in the same run or left over from a run that stopped right after pushing it) and still forces the dependent's patch release, rather than depending on a record that only ever existed in the process that made the commit.
 
@@ -42,7 +43,7 @@ Dependency-range handling, in full:
 
 | Range in the dependent's manifest | What happens |
 | --- | --- |
-| `^1.0.0`, `~1.0.0`, `>=1.0.0`, `=1.0.0`, `1.0.0`, `workspace:^1.0.0` | Rewritten in place, preserving the comparator (`^1.0.0` → `^1.1.0`), committed and pushed; dependent gets at least a patch release |
+| `^1.0.0`, `~1.0.0`, `>=1.0.0`, `=1.0.0`, `1.0.0`, `workspace:^1.0.0` | Rewritten in place, preserving the comparator (`^1.0.0` → `^1.1.0`); `pnpm-lock.yaml` is regenerated to match, and both are committed and pushed together; dependent gets at least a patch release |
 | `workspace:*`, `workspace:^`, `workspace:~` | No manifest edit (pnpm resolves these at pack time), but the published range still changes, so the dependent still gets a patch release |
 | `*`, `x`, `latest` | Nothing to update and the published range is unaffected — no bump, no forced release |
 | Compound ranges (`>=1.0.0 <2.0.0`), unions (`1.x \|\| 2.x`), `<`/`<=` bounds, `catalog:`, `npm:` aliases, git/tarball URLs | The run stops with `UnsupportedDependencyRangeError` — rewriting any of these wrongly, or leaving them silently stale, both produce a published manifest that disagrees with the repository, so neither is attempted |

package/dist/cli.js

@@ -13,7 +13,7 @@ import validateNpmPackageName from "validate-npm-package-name";
 import { glob } from "tinyglobby";
 import { parse } from "yaml";
 //#region package.json
-var version = "1.0.2";
+var version = "1.0.3";
 //#endregion
 //#region src/errors.ts
 /**
@@ -52,6 +52,12 @@ var GitCommandError = class extends WorkspaceReleaseError {
 };
 /** The workspace's git state does not support the release operation -- for example a detached HEAD, which names no branch that dependency-bump commits could be pushed to. */
 var WorkspaceStateError = class extends WorkspaceReleaseError {};
+/** `pnpm install --lockfile-only` failed while regenerating the lockfile for a dependency-range bump. Left unhandled, a dependent's manifest would be committed with `pnpm-lock.yaml` still naming the old range -- the exact drift this step exists to prevent -- so the bump aborts instead of committing a manifest and lockfile that disagree. */
+var PnpmCommandError = class extends WorkspaceReleaseError {
+	constructor(cwd, detail) {
+		super(`pnpm install --lockfile-only failed in ${cwd}: ${detail}`);
+	}
+};
 //#endregion
 //#region src/json.ts
 function isJsonObject(value) {
@@ -125,7 +131,7 @@ function matchTrailerLine(message, key) {
 }
 //#endregion
 //#region src/git.ts
-const execFileAsync = promisify(execFile);
+const execFileAsync$1 = promisify(execFile);
 /** `git log --name-only` over everything since a package's last release tag can legitimately produce tens of megabytes of path output on a long-lived monorepo, well past execFile's default buffer, failing on exactly the big workspaces this tool exists for. */
 const GIT_MAX_BUFFER_BYTES = 104857600;
 /** Separates one commit's record in `git log --format` output. Chosen from the C0 control range so it can never appear in a hash or a file path. */
@@ -137,7 +143,7 @@ const BOT_IDENTITY = {
 };
 async function git(args, options) {
 	try {
-		const { stdout } = await execFileAsync("git", [...args], {
+		const { stdout } = await execFileAsync$1("git", [...args], {
 			cwd: options.cwd,
 			maxBuffer: GIT_MAX_BUFFER_BYTES
 		});
@@ -564,6 +570,23 @@ function firstUnplacedDependency(name, graph, unplaced) {
 	return (graph.dependencies.get(name) ?? []).map((edge) => edge.dependency).filter((dependency) => unplaced.has(dependency)).sort()[0];
 }
 //#endregion
+//#region src/pnpm.ts
+const execFileAsync = promisify(execFile);
+/**
+* Regenerates `pnpm-lock.yaml` for the whole workspace from the manifests currently on disk, without touching `node_modules` or installing anything -- the same lockfile-refresh step a contributor runs by hand after editing a `package.json` dependency range.
+*
+* Every dependency-range bump this tool writes to a manifest must be followed by this before the bump is committed: `pnpm install --frozen-lockfile` (what CI runs) rejects a tree where the lockfile's recorded specifier for a workspace dependency disagrees with the manifest, so a manifest bump committed without a matching lockfile update leaves every subsequent CI run broken until someone runs `pnpm install` by hand and commits the result.
+*/
+async function regenerateLockfile(options) {
+	try {
+		await execFileAsync("pnpm", ["install", "--lockfile-only"], { cwd: options.cwd });
+	} catch (cause) {
+		const stderr = cause instanceof Error && "stderr" in cause && typeof cause.stderr === "string" ? cause.stderr.trim() : "";
+		const detail = stderr !== "" ? stderr : cause instanceof Error ? cause.message : String(cause);
+		throw new PnpmCommandError(options.cwd, detail);
+	}
+}
+//#endregion
 //#region src/version-range.ts
 const WORKSPACE_PROTOCOL = "workspace:";
 const CATALOG_PROTOCOL = "catalog:";
@@ -727,10 +750,12 @@ async function runPackageRelease(pkg, options) {
 		throw new WorkspaceReleaseError(`Release of ${pkg.name} failed: ${cause instanceof Error ? cause.message : String(cause)}`);
 	}
 }
+/** The one filename pnpm recognises as its lockfile, always sitting beside `pnpm-workspace.yaml` at the workspace root regardless of which dependent's manifest a bump rewrites. */
+const LOCKFILE_FILENAME = "pnpm-lock.yaml";
 /**
 * Rewrites the released package's range in every dependent's manifest, immediately after the release and before any dependent's own turn.
 *
-* The bump is committed (and pushed) right away rather than staged, because a dependent's semantic-release run analyses git history, not the working tree: an uncommitted bump would be invisible to its commit analysis, and would be stranded uncommitted if the dependent then released nothing -- a manifest that names versions the registry has never seen. Committing immediately means the dependent's own run sees the bump commit (it touches only the dependent's directory, so it passes that dependent's path filter), the forced-patch logic in the scoped analyzer covers the case where that bump is the dependent's only change, and a run interrupted partway leaves the remote describing exactly what was published. Pushing immediately mirrors what semantic-release itself does with release commits.
+* The bump is committed (and pushed) right away rather than staged, because a dependent's semantic-release run analyses git history, not the working tree: an uncommitted bump would be invisible to its commit analysis, and would be stranded uncommitted if the dependent then released nothing -- a manifest that names versions the registry has never seen. Committing immediately means the dependent's own run sees the bump commit (it touches only the dependent's directory, so it passes that dependent's path filter), the forced-patch logic in the scoped analyzer covers the case where that bump is the dependent's only change, and a run interrupted partway leaves the remote describing exactly what was published. Pushing immediately mirrors what semantic-release itself does with release commits. The lockfile is regenerated (`pnpm install --lockfile-only`) and committed alongside the manifest for the same reason: a manifest bump committed without it leaves `pnpm-lock.yaml` naming the old range, which `pnpm install --frozen-lockfile` (what CI runs) then rejects.
 */
 async function bumpDependents(released, version, graph, options) {
 	const applied = [];
@@ -743,18 +768,19 @@ async function bumpDependents(released, version, graph, options) {
 		if (update.kind === "rewritten") {
 			if (!options.dryRun) {
 				await writeDependencyRange(dependent.manifestPath, edge.field, released.name, update.range);
+				await regenerateLockfile({ cwd: options.workspace.root });
 				const message = formatDependencyBumpMessage({
 					dependency: released.name,
 					version,
 					range: update.range,
 					dependent: edge.dependent
 				});
-				await commitFiles([`${dependent.relativeDirectory}/package.json`], message, {
+				await commitFiles([`${dependent.relativeDirectory}/package.json`, LOCKFILE_FILENAME], message, {
 					cwd: options.workspace.root,
 					identity: options.identity
 				});
 				await pushHead({ cwd: options.workspace.root });
-				options.log(`Bumped ${released.name} to ${update.range} in ${edge.dependent}, committed and pushed`);
+				options.log(`Bumped ${released.name} to ${update.range} in ${edge.dependent}, regenerated the lockfile, committed and pushed`);
 			} else options.log(`Would bump ${released.name} to ${update.range} in ${edge.dependent} (${edge.field})`);
 		} else options.log(`${edge.dependent} declares ${released.name} as ${edge.range}; the manifest needs no edit, pnpm re-resolves it to ${version} at publish time`);
 		applied.push({

package/dist/index.cjs

@@ -74,9 +74,15 @@ var GitCommandError = class extends WorkspaceReleaseError {
 };
 /** The workspace's git state does not support the release operation -- for example a detached HEAD, which names no branch that dependency-bump commits could be pushed to. */
 var WorkspaceStateError = class extends WorkspaceReleaseError {};
+/** `pnpm install --lockfile-only` failed while regenerating the lockfile for a dependency-range bump. Left unhandled, a dependent's manifest would be committed with `pnpm-lock.yaml` still naming the old range -- the exact drift this step exists to prevent -- so the bump aborts instead of committing a manifest and lockfile that disagree. */
+var PnpmCommandError = class extends WorkspaceReleaseError {
+	constructor(cwd, detail) {
+		super(`pnpm install --lockfile-only failed in ${cwd}: ${detail}`);
+	}
+};
 //#endregion
 //#region src/git.ts
-const execFileAsync = (0, node_util.promisify)(node_child_process.execFile);
+const execFileAsync$1 = (0, node_util.promisify)(node_child_process.execFile);
 /** `git log --name-only` over everything since a package's last release tag can legitimately produce tens of megabytes of path output on a long-lived monorepo, well past execFile's default buffer, failing on exactly the big workspaces this tool exists for. */
 const GIT_MAX_BUFFER_BYTES = 104857600;
 /** Separates one commit's record in `git log --format` output. Chosen from the C0 control range so it can never appear in a hash or a file path. */
@@ -88,7 +94,7 @@ const BOT_IDENTITY = {
 };
 async function git(args, options) {
 	try {
-		const { stdout } = await execFileAsync("git", [...args], {
+		const { stdout } = await execFileAsync$1("git", [...args], {
 			cwd: options.cwd,
 			maxBuffer: GIT_MAX_BUFFER_BYTES
 		});
@@ -641,6 +647,23 @@ function parsePublishPluginSpec(spec) {
 	return [name, config ?? {}];
 }
 //#endregion
+//#region src/pnpm.ts
+const execFileAsync = (0, node_util.promisify)(node_child_process.execFile);
+/**
+* Regenerates `pnpm-lock.yaml` for the whole workspace from the manifests currently on disk, without touching `node_modules` or installing anything -- the same lockfile-refresh step a contributor runs by hand after editing a `package.json` dependency range.
+*
+* Every dependency-range bump this tool writes to a manifest must be followed by this before the bump is committed: `pnpm install --frozen-lockfile` (what CI runs) rejects a tree where the lockfile's recorded specifier for a workspace dependency disagrees with the manifest, so a manifest bump committed without a matching lockfile update leaves every subsequent CI run broken until someone runs `pnpm install` by hand and commits the result.
+*/
+async function regenerateLockfile(options) {
+	try {
+		await execFileAsync("pnpm", ["install", "--lockfile-only"], { cwd: options.cwd });
+	} catch (cause) {
+		const stderr = cause instanceof Error && "stderr" in cause && typeof cause.stderr === "string" ? cause.stderr.trim() : "";
+		const detail = stderr !== "" ? stderr : cause instanceof Error ? cause.message : String(cause);
+		throw new PnpmCommandError(options.cwd, detail);
+	}
+}
+//#endregion
 //#region src/release.ts
 /**
 * Releases every package in a pnpm workspace with independent versions, in dependency order.
@@ -740,10 +763,12 @@ async function runPackageRelease(pkg, options) {
 		throw new WorkspaceReleaseError(`Release of ${pkg.name} failed: ${cause instanceof Error ? cause.message : String(cause)}`);
 	}
 }
+/** The one filename pnpm recognises as its lockfile, always sitting beside `pnpm-workspace.yaml` at the workspace root regardless of which dependent's manifest a bump rewrites. */
+const LOCKFILE_FILENAME = "pnpm-lock.yaml";
 /**
 * Rewrites the released package's range in every dependent's manifest, immediately after the release and before any dependent's own turn.
 *
-* The bump is committed (and pushed) right away rather than staged, because a dependent's semantic-release run analyses git history, not the working tree: an uncommitted bump would be invisible to its commit analysis, and would be stranded uncommitted if the dependent then released nothing -- a manifest that names versions the registry has never seen. Committing immediately means the dependent's own run sees the bump commit (it touches only the dependent's directory, so it passes that dependent's path filter), the forced-patch logic in the scoped analyzer covers the case where that bump is the dependent's only change, and a run interrupted partway leaves the remote describing exactly what was published. Pushing immediately mirrors what semantic-release itself does with release commits.
+* The bump is committed (and pushed) right away rather than staged, because a dependent's semantic-release run analyses git history, not the working tree: an uncommitted bump would be invisible to its commit analysis, and would be stranded uncommitted if the dependent then released nothing -- a manifest that names versions the registry has never seen. Committing immediately means the dependent's own run sees the bump commit (it touches only the dependent's directory, so it passes that dependent's path filter), the forced-patch logic in the scoped analyzer covers the case where that bump is the dependent's only change, and a run interrupted partway leaves the remote describing exactly what was published. Pushing immediately mirrors what semantic-release itself does with release commits. The lockfile is regenerated (`pnpm install --lockfile-only`) and committed alongside the manifest for the same reason: a manifest bump committed without it leaves `pnpm-lock.yaml` naming the old range, which `pnpm install --frozen-lockfile` (what CI runs) then rejects.
 */
 async function bumpDependents(released, version, graph, options) {
 	const applied = [];
@@ -756,18 +781,19 @@ async function bumpDependents(released, version, graph, options) {
 		if (update.kind === "rewritten") {
 			if (!options.dryRun) {
 				await writeDependencyRange(dependent.manifestPath, edge.field, released.name, update.range);
+				await regenerateLockfile({ cwd: options.workspace.root });
 				const message = formatDependencyBumpMessage({
 					dependency: released.name,
 					version,
 					range: update.range,
 					dependent: edge.dependent
 				});
-				await commitFiles([`${dependent.relativeDirectory}/package.json`], message, {
+				await commitFiles([`${dependent.relativeDirectory}/package.json`, LOCKFILE_FILENAME], message, {
 					cwd: options.workspace.root,
 					identity: options.identity
 				});
 				await pushHead({ cwd: options.workspace.root });
-				options.log(`Bumped ${released.name} to ${update.range} in ${edge.dependent}, committed and pushed`);
+				options.log(`Bumped ${released.name} to ${update.range} in ${edge.dependent}, regenerated the lockfile, committed and pushed`);
 			} else options.log(`Would bump ${released.name} to ${update.range} in ${edge.dependent} (${edge.field})`);
 		} else options.log(`${edge.dependent} declares ${released.name} as ${edge.range}; the manifest needs no edit, pnpm re-resolves it to ${version} at publish time`);
 		applied.push({

package/dist/index.js

@@ -49,9 +49,15 @@ var GitCommandError = class extends WorkspaceReleaseError {
 };
 /** The workspace's git state does not support the release operation -- for example a detached HEAD, which names no branch that dependency-bump commits could be pushed to. */
 var WorkspaceStateError = class extends WorkspaceReleaseError {};
+/** `pnpm install --lockfile-only` failed while regenerating the lockfile for a dependency-range bump. Left unhandled, a dependent's manifest would be committed with `pnpm-lock.yaml` still naming the old range -- the exact drift this step exists to prevent -- so the bump aborts instead of committing a manifest and lockfile that disagree. */
+var PnpmCommandError = class extends WorkspaceReleaseError {
+	constructor(cwd, detail) {
+		super(`pnpm install --lockfile-only failed in ${cwd}: ${detail}`);
+	}
+};
 //#endregion
 //#region src/git.ts
-const execFileAsync = promisify(execFile);
+const execFileAsync$1 = promisify(execFile);
 /** `git log --name-only` over everything since a package's last release tag can legitimately produce tens of megabytes of path output on a long-lived monorepo, well past execFile's default buffer, failing on exactly the big workspaces this tool exists for. */
 const GIT_MAX_BUFFER_BYTES = 104857600;
 /** Separates one commit's record in `git log --format` output. Chosen from the C0 control range so it can never appear in a hash or a file path. */
@@ -63,7 +69,7 @@ const BOT_IDENTITY = {
 };
 async function git(args, options) {
 	try {
-		const { stdout } = await execFileAsync("git", [...args], {
+		const { stdout } = await execFileAsync$1("git", [...args], {
 			cwd: options.cwd,
 			maxBuffer: GIT_MAX_BUFFER_BYTES
 		});
@@ -616,6 +622,23 @@ function parsePublishPluginSpec(spec) {
 	return [name, config ?? {}];
 }
 //#endregion
+//#region src/pnpm.ts
+const execFileAsync = promisify(execFile);
+/**
+* Regenerates `pnpm-lock.yaml` for the whole workspace from the manifests currently on disk, without touching `node_modules` or installing anything -- the same lockfile-refresh step a contributor runs by hand after editing a `package.json` dependency range.
+*
+* Every dependency-range bump this tool writes to a manifest must be followed by this before the bump is committed: `pnpm install --frozen-lockfile` (what CI runs) rejects a tree where the lockfile's recorded specifier for a workspace dependency disagrees with the manifest, so a manifest bump committed without a matching lockfile update leaves every subsequent CI run broken until someone runs `pnpm install` by hand and commits the result.
+*/
+async function regenerateLockfile(options) {
+	try {
+		await execFileAsync("pnpm", ["install", "--lockfile-only"], { cwd: options.cwd });
+	} catch (cause) {
+		const stderr = cause instanceof Error && "stderr" in cause && typeof cause.stderr === "string" ? cause.stderr.trim() : "";
+		const detail = stderr !== "" ? stderr : cause instanceof Error ? cause.message : String(cause);
+		throw new PnpmCommandError(options.cwd, detail);
+	}
+}
+//#endregion
 //#region src/release.ts
 /**
 * Releases every package in a pnpm workspace with independent versions, in dependency order.
@@ -715,10 +738,12 @@ async function runPackageRelease(pkg, options) {
 		throw new WorkspaceReleaseError(`Release of ${pkg.name} failed: ${cause instanceof Error ? cause.message : String(cause)}`);
 	}
 }
+/** The one filename pnpm recognises as its lockfile, always sitting beside `pnpm-workspace.yaml` at the workspace root regardless of which dependent's manifest a bump rewrites. */
+const LOCKFILE_FILENAME = "pnpm-lock.yaml";
 /**
 * Rewrites the released package's range in every dependent's manifest, immediately after the release and before any dependent's own turn.
 *
-* The bump is committed (and pushed) right away rather than staged, because a dependent's semantic-release run analyses git history, not the working tree: an uncommitted bump would be invisible to its commit analysis, and would be stranded uncommitted if the dependent then released nothing -- a manifest that names versions the registry has never seen. Committing immediately means the dependent's own run sees the bump commit (it touches only the dependent's directory, so it passes that dependent's path filter), the forced-patch logic in the scoped analyzer covers the case where that bump is the dependent's only change, and a run interrupted partway leaves the remote describing exactly what was published. Pushing immediately mirrors what semantic-release itself does with release commits.
+* The bump is committed (and pushed) right away rather than staged, because a dependent's semantic-release run analyses git history, not the working tree: an uncommitted bump would be invisible to its commit analysis, and would be stranded uncommitted if the dependent then released nothing -- a manifest that names versions the registry has never seen. Committing immediately means the dependent's own run sees the bump commit (it touches only the dependent's directory, so it passes that dependent's path filter), the forced-patch logic in the scoped analyzer covers the case where that bump is the dependent's only change, and a run interrupted partway leaves the remote describing exactly what was published. Pushing immediately mirrors what semantic-release itself does with release commits. The lockfile is regenerated (`pnpm install --lockfile-only`) and committed alongside the manifest for the same reason: a manifest bump committed without it leaves `pnpm-lock.yaml` naming the old range, which `pnpm install --frozen-lockfile` (what CI runs) then rejects.
 */
 async function bumpDependents(released, version, graph, options) {
 	const applied = [];
@@ -731,18 +756,19 @@ async function bumpDependents(released, version, graph, options) {
 		if (update.kind === "rewritten") {
 			if (!options.dryRun) {
 				await writeDependencyRange(dependent.manifestPath, edge.field, released.name, update.range);
+				await regenerateLockfile({ cwd: options.workspace.root });
 				const message = formatDependencyBumpMessage({
 					dependency: released.name,
 					version,
 					range: update.range,
 					dependent: edge.dependent
 				});
-				await commitFiles([`${dependent.relativeDirectory}/package.json`], message, {
+				await commitFiles([`${dependent.relativeDirectory}/package.json`, LOCKFILE_FILENAME], message, {
 					cwd: options.workspace.root,
 					identity: options.identity
 				});
 				await pushHead({ cwd: options.workspace.root });
-				options.log(`Bumped ${released.name} to ${update.range} in ${edge.dependent}, committed and pushed`);
+				options.log(`Bumped ${released.name} to ${update.range} in ${edge.dependent}, regenerated the lockfile, committed and pushed`);
 			} else options.log(`Would bump ${released.name} to ${update.range} in ${edge.dependent} (${edge.field})`);
 		} else options.log(`${edge.dependent} declares ${released.name} as ${edge.range}; the manifest needs no edit, pnpm re-resolves it to ${version} at publish time`);
 		applied.push({

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@exadev/semantic-release-workspace",
-  "version": "1.0.2",
+  "version": "1.0.3",
   "description": "Independent per-package semantic-release orchestration for pnpm workspaces, without lockstep versioning.",
   "type": "module",
   "repository": {