semantic-release / semantic-release/github

publish `dist` directory as `Source code (zip)` asset instead of root

Open
#465 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
534
Forks
150
Avg merge
1m
Merged PRs (30d)
3

Description

My project's build outputs assets to a dist directory. This is what I publish to NPM and it's what I'd like to publish to github.

Here's my config:

module.exports = {
    "plugins": [
        "@semantic-release/commit-analyzer",
        "@semantic-release/release-notes-generator",
        "@semantic-release/changelog",
        ["@semantic-release/npm", {
            "pkgRoot": "dist",
        }],
        "@semantic-release/github",
        "@semantic-release/git"
    ],
    "preset": "angular"
}

This works (mostly). The package is published to NPM and Github but the package that's published to Github as Source code (zip|tar.gz) is the project root, not the dist directory.

Here's an example: https://github.com/gpspake/npm-demo-shared-dependency/releases/tag/v1.1.4

@semantic-release/npm has a pkgRoot option that can be used to specify which directory to publish

["@semantic-release/npm", {
    "pkgRoot": "dist",
}],

I figured the assets option would work the same way so tried setting it to dist and dist/** but that just publishes the flat files (in addition to the compressed source from the root directory)

["@semantic-release/github", {
    "assets": "dist/**"
}],

Is there a "pkgRoot" equivalent for @semantic-release/github or an implicit way to specify that?
Or am I missing some obvious reason I wouldn't need it? 🙂

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the release using the provided @semantic-release/github configuration and the linked v1.1.4 example, then inspect how the plugin handles the assets option and GitHub's generated source archives. Done means the release behavior for a dist directory is defined and covered by an appropriate test or documented limitation.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, javascript
Domain
release
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.