Semantic release updates a file correctly, but doesn't include it in the release

[testasoft]

Hi,

In our semantic release, we added a simple additional step - running a shell script that updates src/Constants/Package.ts file. On inspection we see, that the file is updated and committed. The chore(release) commit includes the correct version of Package.ts file. However the final build of the package only includes the previous state of Package.ts. Meaning, that each subsequent build will have the previous version of Package.ts. So how could the release part ignore the new state of Package.ts, but accept changes on package.json or changelog?

Here's the release.config.js:
export function semanticReleaseConfig(params: Params = defaultParams) { return { branches: [ '+([0-9])?(.{+([0-9]),x}).x', params.defaultBranch ?? defaultParams.defaultBranch, 'next', 'next-major', { name: 'beta', prerelease: true }, { name: 'alpha', prerelease: true }, { name: 'rc', prerelease: true }, ], plugins: [ '@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/changelog', '@semantic-release/gitlab', [ '@semantic-release/npm', { npmPublish: true }, ], [ '@semantic-release/exec', { prepareCmd: './version.sh ${nextRelease.version}', }, ], [ '@semantic-release/git', { assets: [ 'CHANGELOG.md', 'package.json', 'package-lock.json', 'src/Constants/Package.ts', ], }, ], ], }; }

[BinToss]

This is issue appears to be unrelated to @semantic-release/git.

---

(OP's config. Pretty printed, enclosed in TS codeblock, and stripped down to the important part)

{
  plugins: [
    ["@semantic-release/npm", { npmPublish: true }],
    [
      "@semantic-release/exec",
      { prepareCmd: "./version.sh ${nextRelease.version}" },
    ],
    [
      "@semantic-release/git",
      {
        assets: [
          "CHANGELOG.md",
          "package.json",
          "package-lock.json",
          "src/Constants/Package.ts",
        ],
      },
    ],
  ],
}

Plugin load order is very important. Your config is telling semantic-release to run @semantic-release/npm's prepare step (packaging, presumably) to run before @semantic-release/exec's prepare.
See https://github.com/semantic-release/semantic-release/blob/master/docs/usage/plugins.md

Solution

export function semanticReleaseConfig(params: Params = defaultParams) {
  return {
    branches: [
      "+([0-9])?(.{+([0-9]),x}).x",
      params.defaultBranch ?? defaultParams.defaultBranch,
      "next",
      "next-major",
      { name: "beta", prerelease: true },
      { name: "alpha", prerelease: true },
      { name: "rc", prerelease: true },
    ],
    plugins: [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      "@semantic-release/changelog",
      [
        "@semantic-release/exec",
        { prepareCmd: "./version.sh ${nextRelease.version}" },
      ],
      [
        "@semantic-release/git",
        {
          assets: [
            "CHANGELOG.md",
            "package.json",
            "package-lock.json",
            "src/Constants/Package.ts",
          ],
        },
      ],
      ["@semantic-release/npm", { npmPublish: true }],
      "@semantic-release/gitlab",
    ],
  };
}

In summary, this config causes the following order of operations:

# I added Exec to only the steps it's configured to run in. I also omitted the `success` and `fail` steps which occur before, during, and after many other steps.

Order Of Execution By Step:
  # verify conditions necessary to proceed with the release: configuration is correct, authentication token are valid, etc...
  verifyConditions:
    # Verify the changelogFile and changelogTitle options configuration.
    - semantic-release/changelog
    # Create a release commit, including configurable file assets.
    - semantic-release/exec
    # Verify the presence of the NPM_TOKEN environment variable, or an .npmrc file, and verify the authentication method is valid.
    - semantic-release/npm
    # Verify the presence and the validity of the authentication (set via environment variables).
    - semantic-release/gitlab

  # add a release channel (e.g. adding an npm dist-tag to a release).
  addChannel:
    # Add a release to a dist-tag.
    - semantic-release/npm

  # determine the type of the next release (major, minor or patch). If multiple plugins with a analyzeCommits step are defined, the release type will be the highest one among plugins output.
  analyzeCommits:
    # Determine the type of release by analyzing commits with conventional-changelog.
    - semantic-release/commit-analyzer

  # verify the parameters (version, type, dist-tag etc...) of the release that is about to be published.
  verifyRelease:

  # generate the content of the release note. If multiple plugins with a generateNotes step are defined, the release notes will be the result of the concatenation of each plugin output.
  generateNotes:
    # Generate release notes for the commits added since the last release with conventional-changelog.
    - semantic-release/release-notes-generator

  # create or update files such as package.json, CHANGELOG.md, documentation or compiled assets
  # and push a commit.
  prepare:
    # Create or update a changelog file in the local project directory with the changelog content created in the generate notes step.
    - semantic-release/changelog
    # Create a release commit, including configurable file assets.
    - semantic-release/git
    # Update the package.json version and create the npm package tarball.
    - semantic-release/npm
    - - semantic-release/exec
      - prepareCmd: "./version.sh ${nextRelease.version}"

  publish:
    # Publish the npm package to the registry.
    - semantic-release/npm
    # Publish a GitLab release.
    - semantic-release/gitlab

[testasoft]

Hi, makes sense, but from what you wrote in your last code block, it looks like the preparation step of npm plugin happens before the /exec plugin. Am I missing something?

After switching exec and npm parts, the result is still the same - the change I need is committed, but not packaged :(

[testasoft]

Looks like the order is correct.. It feels like npm prepare works on a completely separate clone of the codebase. exec makes the changes separately

[BinToss]

All plugins are scoped to the NodeJS process's current working directory unless something explicitly changes it.

You can troubleshoot by adding an echo to each of Exec steps' commands to output whether or not a given file exists. That should help you determine if the file is ever created at the expected path.

If it never exists at the expected path, echo the paths of the created file if you can. Otherwise, dir/ls the working directory and the file system root directory. I've had files created at root because of bad string formatting.

[testasoft]

Do you mean that the file might not exist during /npm prepare steps, but exists during git/exec?

As stated previously, the /exec part does exactly what I need it to do. After that, the /git plugin successfully commits the file that I changed during the semantic release. Only /npm plugin won't package the newly updated file for some reason :(