The getMonorepoPackage() function returns the highest version package within the monorepo, but pays no respect to .gitignored values.
|
export function getMonorepoPackage() { |
|
const packages = getPackages(process.cwd()); |
|
|
|
if (!packages.length) { |
|
return {} as IPackageJSON; |
|
} |
|
|
|
// Remove pre-releases so that released package versions take precedence |
|
let releasedPackages = packages.filter( |
|
(subPackage) => prerelease(subPackage.package?.version || "") === null |
|
); |
|
// If doing this would remove all packages, this means were not any @latest releases yet |
|
// In that case, restore the original list of packages. |
|
if (releasedPackages.length === 0) { |
|
releasedPackages = packages; |
|
} |
|
|
|
const monorepoPackage = releasedPackages.reduce((greatest, subPackage) => { |
|
if (subPackage.package.version) { |
|
if (!greatest.package.version) { |
|
return subPackage; |
|
} |
|
|
|
if (subPackage.package.private) { |
|
return greatest; |
|
} |
|
|
|
return gt(greatest.package.version, subPackage.package.version) |
|
? greatest |
|
: subPackage; |
|
} |
|
|
|
return greatest; |
|
}); |
|
|
|
return monorepoPackage.package; |
|
} |
For example, our monorepo contains these packages declared in lerna.json:
"version": "22.1.0",
"packages": [
"packages/*",
"examples/**",
"templates/*",
"tasks",
"deprecated/*"
]
lerna@8.1.8 returns the following for npx lerna ls (lightly modified to de-name stuff):
> npx lerna exec pwd
lerna notice cli v8.1.8
lerna info Executing command in 25 packages: "pwd"
(... some dependency cycle warnings ...)
/Users/me/my-org/my-monorepo/tasks
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-1
/Users/me/my-org/my-monorepo/packages/package-1
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-2
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-3
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-4
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-5
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-6
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-7
/Users/me/my-org/my-monorepo/packages/package-2
/Users/me/my-org/my-monorepo/packages/package-3
/Users/me/my-org/my-monorepo/packages/package-4
/Users/me/my-org/my-monorepo/packages/package-5
/Users/me/my-org/my-monorepo/templates/template-package-1
/Users/me/my-org/my-monorepo/packages/package-6
/Users/me/my-org/my-monorepo/packages/package-7
/Users/me/my-org/my-monorepo/packages/package-8
/Users/me/my-org/my-monorepo/examples/package-6/example-custom
/Users/me/my-org/my-monorepo/examples/package-6/example-default
/Users/me/my-org/my-monorepo/templates/template-package-2
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-8
/Users/me/my-org/my-monorepo/examples/package-7/example-custom
/Users/me/my-org/my-monorepo/examples/package-7/example-default
/Users/me/my-org/my-monorepo/templates/template-package-3
/Users/me/my-org/my-monorepo/packages/package-9
lerna success exec Executed command in 25 packages: "pwd"
Recently we added jest@29.7.0 to the package-7/example-default and package-7/example-custom apps and then released a major. Given we were on 22.1.0, we expected a release of 23.0.0 but instead received 30.0.0. We bumped our logs up to veryVerbose and dug through and found 3 references within an invocation of npx auto shipit for the monorepo version being resolved at 29.7.0, 22.1.0, and 22.1.0:
npx auto shipit output lines 570-1093 (references v29.7.0):
+ℹ info NPM: Got previous version from package.json v29.7.0
ℹ info Getting labels for project: praxis
ℹ info Found labels on project:
[
...
]
Environment Information:
"auto" version: v10.43.0
"git" version: v2.39.2
"node" version: v20.16.0
GHE version: v3.11.7
Project Information:
✔ Repository: my-org/my-monorepo (https://<github_enterprise>/my-org/my-monorepo)
✔ Author Name:
✔ Author Email:
+✔ Current Version: v29.7.0
✔ Latest Release: v22.1.0 (https://<github_enterprise>/my-org/my-monorepo/releases/tag/v22.1.0)
npx auto shipit output lines 570-1093 (references v22.1.0 2x):
+ℹ info NPM: Got previous version from package.json v22.1.0
ℹ info Adding new changes to CHANGELOG.md.
ℹ info Calculating SEMVER bump using:
{
labels: [
...
],
versionLabels: Map(6) {
...
},
options: { onlyPublishWithReleaseLabel: undefined }
}
✔ success Calculated SEMVER bump: major
ℹ info Calculated next version to be: 23.0.0
ℹ info Old changelog exists, prepending changes.
ℹ info Wrote new changelog to filesystem.
+ℹ info NPM: Got previous version from package.json v22.1.0
✔ success Created old version branch: release-22
⚠ warning Everything up-to-date
Notably, /Users/me/my-org/my-monorepo/examples/package-7/example-default/node_modules/jest does not appear in the npx lerna ls output above, so auto's resolution of monorepo packages in this regard differs from lerna's resolution.
I do realize and acknowledge that (as I learned yesterday) adding foo/** patterns as packages is not a recommended pattern. We have now worked through the issue by dropping 'examples/**' in favor of 'examples/*', 'examples/*/*'.
The
getMonorepoPackage()function returns the highest version package within the monorepo, but pays no respect to.gitignored values.auto/plugins/npm/src/index.ts
Lines 156 to 192 in be95283
For example, our monorepo contains these
packagesdeclared inlerna.json:lerna@8.1.8returns the following fornpx lerna ls(lightly modified to de-name stuff):Recently we added
jest@29.7.0to thepackage-7/example-defaultandpackage-7/example-customapps and then released a major. Given we were on22.1.0, we expected a release of23.0.0but instead received30.0.0. We bumped our logs up to veryVerbose and dug through and found 3 references within an invocation ofnpx auto shipitfor the monorepo version being resolved at29.7.0,22.1.0, and22.1.0:npx auto shipitoutput lines 570-1093 (referencesv29.7.0):npx auto shipitoutput lines 570-1093 (referencesv22.1.02x):Notably,
/Users/me/my-org/my-monorepo/examples/package-7/example-default/node_modules/jestdoes not appear in thenpx lerna lsoutput above, soauto's resolution of monorepo packages in this regard differs from lerna's resolution.I do realize and acknowledge that (as I learned yesterday) adding
foo/**patterns aspackagesis not a recommended pattern. We have now worked through the issue by dropping'examples/**'in favor of'examples/*', 'examples/*/*'.