embroider-build / release-plan Goto Github PK

right now the default is quite large and is talking about the merge commit not the version, I just want to improve it

https://github.blog/2023-04-19-introducing-npm-package-provenance/

This would be implemented in exactly the same way that we added #38 so it would be passed through the publish command 👍

So I was evaluating using this for releasing projects over at the @ember-tooling org. Most of what we need to publish are VSCode extensions though and right now npm is a baked in assumption of release plan.

One idea I came up with was having some way for a project to supply a custom publishing strategy by passing in a PublishStrategy class that would potentially look something like this.

import { PublishStrategy } from 'release-plan';

export default class VSCodeStrategy extends PublishStrategy {
  async doesVersionExist() {
    // do thing to determine version exists

    if (itExists) {
      return true;
    }
    
    return false;
  }

  async publish() {
    // do your publish steps

    if (isPublished) {
      return true;
    }
    
    return false;
  }
}

I think this would work by running a command similar to this

$ release-plan publish --strategy ./publish/vscode.js 

Popular strategies could potentially be merged back upstream and named so you can do things like this

$ release-plan publish --strategy vscode
$ release-plan publish --strategy npm
$ release-plan publish --strategy dockerhub

I'd like to take a stab at a proof of concept on this but creating this issue initially for feedback or other ideas.

Extra context https://github.com/orgs/ember-tooling/discussions/1

https://pnpm.io/npmrc#shared-workspace-lockfile

The reason I needed this was for extreme isolation between workspaces.

The actual problem is with @ef4/lerna-changelog, but I wonder if we should just move that code into release-plan?

Here is the code that errors, (due to not-quite-json)

❯ pnpm m ls --json --depth=-1
[
  {
    "path": "/home/nvp/Development/NullVoxPopuli/ember-resources-2",
    "private": true
  }
]
[
  {
    "name": "@nullvoxpopuli/estimate-bytes",
    "path": "/home/nvp/Development/NullVoxPopuli/ember-resources-2/dev/estimate-bytes",
    "private": true
  }
]
[
  {
    "name": "docs",
    "version": "0.0.0",
    "path": "/home/nvp/Development/NullVoxPopuli/ember-resources-2/docs",
    "private": true
  }
]
[
  {
    "name": "ember-resources",
    "version": "6.5.0",
    "path": "/home/nvp/Development/NullVoxPopuli/ember-resources-2/ember-resources",
    "private": false
  }
]
[
  {
    "name": "test-app",
    "version": "0.0.0",
    "path": "/home/nvp/Development/NullVoxPopuli/ember-resources-2/test-app",
    "private": true
  }
]
[
  {
    "name": "test-app-definitely-typed",
    "version": "0.0.0",
    "path": "/home/nvp/Development/NullVoxPopuli/ember-resources-2/test-app-definitely-typed",
    "private": true
  }
]

from:

       │ File: /home/nvp/Development/NullVoxPopuli/ember-resources-2/node_modules/.pnpm/@[email protected]/node_modules/@ef4/lerna-changelog/lib/configuration.js

As it turns out, this is blocking the release of ember-resources@v7 😅

https://github.com/NullVoxPopuli/ember-resources/actions/runs/7482171149/job/20365200936

#35 introduces a workaround for this repo because pnpm is acting badly. It would be nice to fix this before 1.0 but at the very least we should document it somewhere 🤷

I added a hack in #5 that worked around the fact that this was originally designed to work with a monorepo. it's a totally unnecessary command since we can probably figure out if we're in a monorepo automatically

We should remove the need for this command before 1.0

for example:

• pnpm update
• other dev tools

renovate tags these with dependencies, yet release-plan categorizes these as "unlabeled", which isn't true, but also -- should the changelog care?
should we add dependencies to our changelog generation?

example:

release-plan was originally extracted from embroider to manage the release of a complicated monorepo tree of dependencies.

Embroider also has another feature, "unstable releases" that was not managed by release-plan because it pre-dates the creation of this package. The unstable releases always just do a next patch version and add -unstable.<sha> to the end but it would be nice to add this functionality to release-plan so it would actually be a major if the next release would be a major 👍

Here is the code for the unstable release: https://github.com/embroider-build/embroider/tree/main/test-packages/unstable-release

Wondering how to use this with prereleases. Thanks in advance!

This keeps coming up, so I made a table:

excerpt from: https://github.com/orgs/ember-tooling/discussions/1#discussioncomment-8447957

From reading the repo it seems like a bunch of manual steps similar to release-it?

Readme may need updating then... because nothing is manual. Release-it is manual by comparison, as is changesets.

cc @mansona

But the way it works:

Access:

number of steps:

• release-plan: 5
• release-it: 6
  Downsides:
  • maintainers need admin access to GH and NPM
  • requires computer
• changesets: 8
  Downsides:
  • requires push access to a submitter's PR
  • more up-front work required
  • hard to go back and add a changeset and have it associated with the PR correctly
  • requires computer

For libraries, it may be beneficial to include code snippets or migration paths, tips, examples, etc in the changelog.

With changesets, this was the main draw -- with release-it, release-plan / everything else, you have to manage that level of detail separately -- but I think it'd be good to have some sort of opt-in... maybe via label (changelog-use-description) or something to include this level of details.

otherwise, you have to remember all that context during changelog creation time as you edit the preview PR before merge.

thoughts?

I'm seeing in the logs:

 Error: Command failed with exit code 128: git describe --abbrev=0 --tags
fatal: No names found, cannot describe anything.

from: https://github.com/NullVoxPopuli/ember-eslint-parser/actions/runs/7255082401/job/19765027127

which does match what I see locally:

❯ git describe --abbrev=0 --tags
fatal: No names found, cannot describe anything.

So, setup-action-pnpm is a meta action, which doesn't really do anything special other than try to interpret the package.json correctly.

For example:

When I tried to setup release-plan on ember-sortable, I was getting errors, because it assumed pnpm 8 -- and like, some file should teh source of truth for that sort of thing (package.json#packageManager is a good such source)

thoughts?

here is the then-resulting upgrade to pnpm-8 to fix release-plan: adopted-ember-addons/ember-sortable#534
(note: volta not used on CI, only some folks' machines)

Here is a preview of what release-plan using wyvox/setup-action-pnpm would look like:
adopted-ember-addons/ember-sortable#535

I think one potential blocking feature that would need to be implemented is a fallback for node version lookup (in action/setup-node) -- I've configured it to look in package.json -- but I don't (yet) know if action/setup-node will continue looking other places if not found -- for example -- in the embroider repo, use-node-version is specified in the .npmrc.

We'll need to PR to here: https://github.com/actions/setup-node/blob/b39b52d1213e96004bfcb1c61a8a6fa8ab84f3e8/src/main.ts#L82
to add support for the .npmrc property that pnpm is looking for