Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved workspace version update to support private packages #497

Merged
merged 2 commits into from
Dec 13, 2024

Conversation

paul-sachs
Copy link
Collaborator

@paul-sachs paul-sachs commented Dec 12, 2024

Just pushing some updates after running through a release and noting some rough edges with scripts.

@paul-sachs paul-sachs marked this pull request as draft December 12, 2024 16:22
@paul-sachs
Copy link
Collaborator Author

Marking as draft until release is done in case there are more changes.

Copy link
Member

@timostamm timostamm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's another issue: The function readPackages expects a directory with packages. It doesn't recognize packages/examples/react/basic as a package.

Comment on lines 71 to 79
if (!pkg.private) {
assert(
l,
`Cannot find lock entry for ${pkg.name} and it is not private`,
);
}
if (l) {
l.version = newVersion;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The lock file should have an entry for every package with a version. If we skip an entry, it will have an old version number. This will lead to problems down the road.

I don't know under which circumstances an entry doesn't have a name. Doesn't seem to be tied to private packages? I've never seen it before.

I suggest we replace lines 68-70 with:

      const l = Object.entries(lock.packages).find(([path, l]) => {
        if ("name" in l) {
          return l.name === pkg.name;
        }
        // In some situations, the entry for a local package doesn't have a "name" property.
        // We check the path of the entry instead: If the last path element is the same as
        // the package name without scope, it's the entry we are looking for.
        return (
          !path.startsWith("node_modules/") &&
          path.split("/").pop() === pkg.name.split("/").pop()
        );
      })?.[1];

@timostamm
Copy link
Member

I think there's another issue: The function readPackages expects a directory with packages. It doesn't recognize packages/examples/react/basic as a package.

The current Node.js LTS - v22 - implements glob. This makes it easy to read all packages:

import { readFileSync, existsSync, globSync } from "node:fs";
import { dirname, join } from "node:path";

/**
 * Read the given root package.json file, and return an array of workspace
 * packages.
 *
 * @param {string} rootPackageJsonPath
 * @return {{path: string, pkg: Record<string, unknown>}[]}
 */
function findWorkspacePackages(rootPackageJsonPath) {
  const root = JSON.parse(readFileSync(rootPackageJsonPath, "utf-8"));
  if (!Array.isArray(root.workspaces) || root.workspaces.some(w => typeof w !== "string")) {
    throw new Error(`Missing or malformed "workspaces" array in ${rootPackageJsonPath}`);
  }
  const rootDir = dirname(rootPackageJsonPath);
  return root.workspaces
    .flatMap(ws => globSync(join(rootDir, ws, "package.json")))
    .filter(path => existsSync(path))
    .map(path => {
      const pkg = JSON.parse(readFileSync(path, "utf-8"));
      return { path, pkg };
    });
}

We can bump to Node v22 (we can still use older versions in CI) and use that. Need to update writePackages a bit. I think it's worth it.

@paul-sachs
Copy link
Collaborator Author

Closing in preference to #499

@paul-sachs paul-sachs closed this Dec 12, 2024
@paul-sachs paul-sachs reopened this Dec 13, 2024
paul-sachs and others added 2 commits December 13, 2024 10:42
Signed-off-by: Paul Sachs <psachs@buf.build>
Signed-off-by: Paul Sachs <psachs@buf.build>
@paul-sachs paul-sachs force-pushed the psachs/fix-release-process-1 branch from 1f0c1eb to 9df0d50 Compare December 13, 2024 15:42
@paul-sachs paul-sachs marked this pull request as ready for review December 13, 2024 15:44
@paul-sachs
Copy link
Collaborator Author

Reopening since I realized #499 was merging into this branch 😵

@paul-sachs paul-sachs merged commit 04a30fd into main Dec 13, 2024
13 checks passed
@paul-sachs paul-sachs deleted the psachs/fix-release-process-1 branch December 13, 2024 15:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants