I'd like to bundle my monorepo into a single file

Could you describe this in more detail? I'd like to understand the context behind the feature request better.

It would be nice to have a hook to run my own custom build process for releases

Could you roughly describe how this would work? Additional question - can assets be attached after the release is already published?

Thank you @Andarist for the reply. Allow me to elaborate:

I am participating in the development of a design system, implemented in an npm monorepo of ~20 web components. Under normal circumstances, users would load whichever components they needed via a module transforming CDN (e.g. unpkg) or with import maps (e.g. jspm), or by npm installing and bundling themselves.

However, many of our users do not want to have to install a node/npm toolchain in order to fetch and bundle our components, and they are prevented by compliance concerns from using third party CDNs like unpkg or jspm

Therefore, we'd like to provide a complete single-file bundle of our design system so that users can download a single javascript file and use it however they like.

Now, from what I gather, I can set up a workflow which bundles the monorepo and uploads it as an asset to an existing release

name: Bundle

on: 
  release: 
    types:
      - published

jobs:
  bundle:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: 16
          cache: npm

      - run: npm i --prefer-offline
      - run: npm run build
      # outputs to /releases/$GITHUB_REF/bundle.min.js
      - run: node scripts/bundle-release.js 
      - uses: actions/github-script@v6
        with:
          script: |
            // yadda yadda
            github.rest.repos.uploadReleaseAsset({
              owner,
              repo,
              release_id,
              name,
              data,
            });

I think the downside to this would be the delay in between creating the release and uploading the asset

Instead, perhaps there could be some assets param to changesets action which looks for assets in a newline-separated string of filenames and attaches them if present

name: Release

on:
  push:
    branches:
      - main
      - master

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: 16
          cache: npm

      - run: npm i --prefer-offline
      - run: npm run build

      - name: Create Release Pull Request or Publish to npm
        uses: changesets/action@v1
        with:
          publish: npx changeset publish
          commit: "chore: version packages"
          # files are uploaded as-is,
          # directories get tarballed then uploaded
          # changesets action could also automatically upload the npm package tarballs
          assets: |
            /releases/${{ env.GITHUB_REF }}/bundle.min.js
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

An important point I missed in yesterday's comment: the config I proposed there (assets key) would not work as shown, since the build process would need to know about the release's metadata via the env

Alternatively, if changesets/action would provide the release ID as an output, users could easily modify the release after publish:

      - name: Create Release Pull Request or Publish to npm
        uses: changesets/action@v1
        id: changesets-release
        with:
          publish: npx changeset publish
          commit: "chore: version packages"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
      - name: Upload Release Asset
        id: upload-release-asset 
        uses: actions/upload-release-asset@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          upload_url: ${{ steps.changesets-release.outputs.release-url }}/upload
          asset_path: ./releases/${{env.GITHUB_REF }}/bundle.min.zip
          asset_name: bundle.min.zip
          asset_content_type: application/zip

Since changesets support monorepo and we can have several different packages released, a singular assets config might not work very well.

If changesets/action would also include release ID in the outputs.publishedPackages for every published/released item, that would help, or perhaps something similar but solely focused on outputting only for released packages.

I'm facing this issue with non-npm packages (applications), and as a workaround I'm going to use whatever is available in the outputs.publishedPackages to craft the lookup tag, then retrieve the release, using the upload URL for every release I'd then compile applications and upload to respected assets. Not ideal, but better than nothing.

It'd be greater if changesets/action could do the heavy lifting though.

If #347 is accepted, then we should be able to upload assets to the releases.