feat: esm

[jpedroh]

BREAKING CHANGE: @semantic-release/commit-analyzer is now a native ES Module

BREAKING CHANGE: When setting the releaseRules option to a path, the path must include the .js extension, and the file must be an ES Module itself, exporting an array as default

Before:

{
  "plugins": [
    ["@semantic-release/commit-analyzer", {
      "preset": "angular",
      "releaseRules": "./config/release-rules"
    }],
    "@semantic-release/release-notes-generator"
  ]
}

// File: config/release-rules.js
module.exports = [
  {type: 'docs', scope: 'README', release: 'patch'},
  {type: 'refactor', scope: 'core-*', release: 'minor'},
  {type: 'refactor', release: 'patch'},
];

After:

{
  "plugins": [
    ["@semantic-release/commit-analyzer", {
      "preset": "angular",
      "releaseRules": "./config/release-rules.js"
    }],
    "@semantic-release/release-notes-generator"
  ]
}

// File: config/release-rules.js
export default [
  {type: 'docs', scope: 'README', release: 'patch'},
  {type: 'refactor', scope: 'core-*', release: 'minor'},
  {type: 'refactor', release: 'patch'},
];

[gr2m]

fyi I rebased on latest beta

[gr2m]

Changes look good to me now.

Anything you'd like to add @jpedroh @travi?

[jpedroh]

Looks good to me.

Let beta begin!

[gr2m]

@travi I'm going to merge, it's only going into the beta anyway, so if we missed something we can still address it in #248

[github-actions]

🎉 This PR is included in version 9.0.0-beta.2 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[travi]

makes sense to me. the only situation i can think of that might cause us to back-track is if we determine that we aren't able to move forward with moving the core package to ESM-only.

just to confirm, does the mention of the async change impact the consumption of this package? i'm mainly trying to consider the consumption in the core package and ensuring that peer dependencies communicate what they should.

[jpedroh]

makes sense to me. the only situation i can think of that might cause us to back-track is if we determine that we aren't able to move forward with moving the core package to ESM-only.

just to confirm, does the mention of the async change impact the consumption of this package? i'm mainly trying to consider the consumption in the core package and ensuring that peer dependencies communicate what they should.

I believe the change won't affect it, since the main package - the one that calls it - is async as well, even before this BC. To my mind, it's just an implementation detail of the module.

[travi]

I believe the change won't affect it, since the main package - the one that calls it - is async as well, even before this BC. To my mind, it's just an implementation detail of the module.

great! thank you for confirming :)