🦋 Changeset detected

Latest commit: 0d3f4db

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Codecov Report

❌ Patch coverage is 91.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 81.34%. Comparing base (3cb9982) to head (0d3f4db).
⚠️ Report is 29 commits behind head on main.

@@           Coverage Diff           @@
##             main    #1795   +/-   ##
=======================================
  Coverage   81.33%   81.34%           
=======================================
  Files          54       54           
  Lines        2277     2278    +1     
  Branches      684      679    -5     
=======================================
+ Hits         1852     1853    +1     
  Misses        420      420           
  Partials        5        5           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@bluwy could you take a look at this PR?
The missing coverage line is not currently covered by tests and was not updated as part of this change.

@Andarist This PR has been open for months without review.

I noticed you added the next label, should I retarget it to the next branch and rebase accordingly?

I’d appreciate a review when possible.
I’ve seen more recent PRs get feedback, so I just want to make sure this one hasn’t been missed.

@marcalexiei ye, we should retarget this to the next branch BUT we need a plan first that will work with our bot, see how we use the packages:
https://github.com/changesets/bot/blob/a443d065be109aeb890cb97c14e5b34e3c4f4a88/get-changed-packages.ts#L184

The problem in there is that we need packages to be fully serializable, or we need to be able to convert the value there into the manypkg Tool object (which probably isn't worth it...). We can freely rely on structural type equivalence (so we don't have to import manypkg itself there)... but we also don't have to if there is a better way.

This might require refactoring the current latest version of manypkg. I'm not sure. If you could do the research around this, it would be very appreciated.

@Andarist As I understand it, the original goal was for assembleReleasePlan to receive a serialisable structure.
With the introduction of the new tool property in manypkg@2 and manypkg@3, that is no longer possible, correct?

I reviewed the following packages:

• assemble-release-plan
• apply-release-plan

In most places, @manypkg/get-packages is used primarily to import the types that define the shape of the packages argument.

Proposal

Introduce a new interface in @changesets/types that defines the expected structure for the packages parameter, and use that internally within the repository.

This would decouple the implementation from @manypkg/get-packages and allow consumers to construct the required structure independently, whether they rely on @manypkg/get-packages or not (E.g. the bot).

The structure would closely resemble Packages from @manypkg/get-packages@1.

Rough Interface Sketch

interface ChangesetPackages {
  rootPackage?: {
    dir: string;
  };
  packages: Array<{
    dir: string;
    // from "@changesets/types"
    packageJson: PackageJSON;
  }>;
}

Would this direction be something you’d consider?

Sounds good. We should also try to handle both manypkg v1 and v2 formats in the bot repo - by detecting what version of Changesets is used by the repo (unless they are completely compatible for our needs)

Sounds good.

Ok, I'll start a new PR from scratch based upon the next branch

We should also try to handle both manypkg v1 and v2 formats in the bot repo - by detecting what version of Changesets is used by the repo (unless they are completely compatible for our needs)

Yes, because the tool property differs significantly between the two versions,
we will inevitably need version-specific handling logic.

Yes, because the tool property differs significantly between the two versions,

Note that we could also consider releasing manypkg v3 to make that project more compatible with what we need it for in Changesets but it would be nice to not lose functionality implemented in v2... But maybe there is some restructuring that can be done to accomplish both needs?

I'm working on this and so far this is what I've created in @changesets/types

export interface ChangesetPackage {
  dir: string;
  packageJson: PackageJSON;
}

// This should be compatible with `@manypkg/get-packages@2`
export type ChangesetPackagesTool = {
  type: "yarn" | "bolt" | "pnpm" | "lerna" | "root" // Picked up from `@manypkg/get-packages@1`
};

export interface ChangesetPackages {
  root: ChangesetPackage;
  packages: Array<ChangesetPackage>;
  tool: ChangesetPackagesTool;
}

Once I have the test and type-check scripts working,
I’ll open a new PR so we can review and discuss the changes in detail.

For now, I won’t update @manypkg/get-packages.