generateNotes step failing

We’ve been using semantic-release-monorepo for a couple months using a lerna project. Been working great until recently this error pops up during generateNotes step:

[2:46:29 PM] [semantic-release] › ℹ  Start step "generateNotes" of plugin "[Function: ]"
[2:46:29 PM] [semantic-release] › ✖  Failed step "generateNotes" of plugin "[Function: ]"
[2:46:29 PM] [semantic-release] › ✖  An error occurred while running semantic-release: { TypeError: Expected `moduleId` to be of type `string`, got `object`
    at resolveFrom (/node_modules/import-from/node_modules/resolve-from/index.js:11:9)
    at module.exports (/node_modules/import-from/node_modules/resolve-from/index.js:34:41)
    at module.exports (/node_modules/import-from/index.js:4:49)
    at requirePlugin (/node_modules/semantic-release-plugin-decorators/src/index.js:4:33)
    at resolvePluginFn (/node_modules/semantic-release-plugin-decorators/src/index.js:18:18)
    at /node_modules/semantic-release-plugin-decorators/src/index.js:26:20
    at validator (/node_modules/semantic-release/lib/plugins/normalize.js:34:28)
    at pReduce (/node_modules/semantic-release/lib/plugins/pipeline.js:37:40)
    at Promise.all.then.value (/node_modules/p-reduce/index.js:16:10)
    at process._tickCallback (internal/process/next_tick.js:68:7) pluginName: '[Function: ]' }

Seems to be some sort of issue with semantic-release-plugin-decorators, which uses import-from to load a plugin, and it’s getting passed an object (I actually think its an array) instead of a string for moduleId which throws.

If I stop extending from semantic-release-monorepo, semantic-release runs fine (but obviously generates bad release notes, etc that aren’t filtered by packages). Any ideas?

We did recently move repo to yarn, not sure if that could cause weirdness. (Update - tested w/ NPM and still seeing same issue…)

Also some info: Tested both semantic-release versions 15.6 and 15.9 Node version 10.8.0 (also tested 10.6.0)

Here’s some additional output showing difference between what gets passed for the analyzeCommits step vs. the generateNotes step: I’m logging the passed moduleId to the console. For analyzeCommits, we have a string, but for generateNotes we have an array containing a string

[3:17:03 PM] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "[Function: ]"
@semantic-release/commit-analyzer
[3:17:04 PM] [semantic-release] [[Function: ]] › ℹ  Found 6 commits for package since last release
[3:17:04 PM] [semantic-release] [[Function: ]] › ℹ  Analysis of 6 commits complete: minor release
[3:17:04 PM] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "[Function: ]"
[3:17:04 PM] [semantic-release] › ℹ  The next release version is 1.1.0
[3:17:04 PM] [semantic-release] › ℹ  Start step "generateNotes" of plugin "[Function: ]"
[ '@semantic-release/release-notes-generator' ]

As a super quick fix, I edited requirePlugin in semantic-release-plugin-decorators/index to this:

const requirePlugin = module => {
  console.log(module);

  if (Array.isArray(module)) {
    return importFrom(process.cwd(), module[0]);
  }

  return importFrom(process.cwd(), module);
};

This solves the issue. I am not sure what could have caused this regression? Also not sure if this is an issue with how the monorepo is using the decorator (wrapPlugin) or in the decorator itself.

[pmowrer]

After digging through this some more, I have a much better understanding of why the error is happening. It has entirely to do with the aforementioned generateNotes plugin interface change that took place in semantic-release in 15.7.0. This interface is already supported, but requires a different but already existing wrapper from the semantic-release-plugin-decorators library.

Initially, I thought fixing it would require a breaking change, as plugin configurations using the “mono” plugin syntax (and not an array) may be incompatible, but I tested it out and it seems to work just fine. I suppose that backwards compatibility is what kept it from being a breaking change in semantic-release to being with. The fix is available in 6.1.0.

Thanks everyone for the help!

[updaterci]

🎉 This issue has been resolved in version 6.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀