Skip to content

Packages should be published in topological order #238

Closed

Description

@Andarist

Affected Packages

I think @changesets/assemble-release-plan should do the sorting.

Problem

A broken release (for example stopped in the middle) might leave NPM registry in a broken state.

Proposed solution

Packages should be published in topological order - dependencies before dependents.

I'm not sure what should be done about cycles.

Activity

  1. emmatown commented on Jan 3, 2020

    @emmatown
    Member

    This sounds fine to me. @changesets/assemble-release-plan wouldn't do the sorting though since it's not related to publishing, it would happen in @changesets/cli.

  2. Andarist commented on Jan 3, 2020

    @Andarist
    MemberAuthor

    My reasoning was that @changesets/assemble-release-plan could output "ready to be published" list - so already presorted with this in mind.

  3. zkochan commented on Apr 15, 2020

    @zkochan
    Contributor

    pnpm publish -r actually publishes packages in topological order. We have a package for sorting the packages: @pnpm/sort-packages.

    You could probably use the graph-sequencer package directly

  4. Andarist commented on Apr 15, 2020

    @Andarist
    MemberAuthor

    @zkochan could u look into internalPublish to see if it satisfies pnpm users? it is executed on per-package basis and it seems that maybe this strategy might not be ideal for some reason when using pnpm?

  5. zkochan commented on Apr 15, 2020

    @zkochan
    Contributor

    The code looks fine. It will probably work fine with pnpm. But I need it to run in topological order because in the pnpm monorepo, the main package should be published last. Before the main package is published, we actually install all of its dependencies before publish, and pack them (kind of like bundled dependencies work).

    Also, I think it would be a good idea to publish all packages with some temporary dist tag and only update all the versions to "latest" when each package has been successfully published.

    This is how Lerna does publishing. pnpm recursive publish also works like that.

  6. zkochan commented on Apr 16, 2020

    @zkochan
    Contributor

    Actually, even if this will be fixed, I will stick with pnpm for doing the publish. changeset publish is extremely slow due to calling npm info on each package in the monorepo. pnpm also checks each version of each package and whether it was released. But pnpm does it using its own programmatic API, concurrently and fast.

  7. Andarist commented on Apr 16, 2020

    @Andarist
    MemberAuthor

    Would you have any direct tips on what you are doing differently to achieve the same result?

  8. zkochan commented on Apr 16, 2020

    @zkochan
    Contributor

    We have this library, called @pnpm/npm-resolver. We run it for every package in the monorepo. It is really fast because it also uses a cache in the filesystem. So if you already checked if [email protected] is published to the repository, the check will not be repeated. Also, it happens concurrently (16 requests at a time) and in the same process, npm is not started for each package, separately.

    Here's the actual step where we do it

    https://github.com/pnpm/pnpm/blob/ee4a5b030b87b28f6086301540bbd806d844910e/packages/plugin-commands-publishing/src/recursivePublish.ts#L61-L69

  9. Andarist commented on Apr 16, 2020

    @Andarist
    MemberAuthor

    So if you already checked if [email protected] is published to the repository, the check will not be repeated.

    I'm not too intimate with the algorithm used here but it seems that this part should be roughly the same as changesets should not need to check if a single package is published multiple times, or does it repeat those calls for some reason?

    The note about reusing npm - I took a quick look at your implementation, npm resolver etc. Could you confirm that you call npm APIs directly rather than using their CLI? And thus it is more lightweight?

  10. zkochan commented on Apr 16, 2020

    @zkochan
    Contributor

    The note about reusing npm - I took a quick look at your implementation, npm resolver etc. Could you confirm that you call npm APIs directly rather than using their CLI? And thus it is more lightweight?

    pnpm has its own API for making requests to the npm registry. That's what we use.

  11. dsogari commented on Mar 8, 2024

    @dsogari

    For anybody who is using plain npm, the "workspaces" field can be specified in topological order, and npm publish --workspaces will respect that order. Unfortunately, changeset publish does not respect it. 😢

    The only issue with using npm directly is that (quoting the docs):

    The publish will fail if the package name and version combination already exists in the specified registry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions