Merge branch 'master' of github.com:semantic-release/semantic-release…

… into beta

.github/workflows/release.yml

@@ -6,8 +6,14 @@ name: Release
       - next
       - beta
       - "*.x"
+permissions:
+  contents: read #  for checkout
 jobs:
   release:
+    permissions:
+      contents: write #  to be able to publish a GitHub release
+      issues: write #  to be able to comment on released issues
+      pull-requests: write #  to be able to comment on released pull requests
     name: release
     runs-on: ubuntu-latest
     steps:

.github/workflows/test.yml

@@ -12,6 +12,9 @@ on:
       - opened
       - synchronize
 
+permissions:
+  contents: read # to fetch code (actions/checkout)
+
 jobs:
   test_matrix:
     strategy:

bin/semantic-release.js

@@ -25,7 +25,7 @@ See https://github.com/semantic-release/semantic-release/blob/master/docs/suppor
 
 execa("git", ["--version"])
   .then(({ stdout }) => {
-    const gitVersion = findVersions(stdout)[0];
+    const gitVersion = findVersions(stdout, { loose: true })[0];
     if (lt(gitVersion, MIN_GIT_VERSION)) {
       console.error(`[semantic-release]: Git version ${MIN_GIT_VERSION} is required. Found ${gitVersion}.`);
       process.exit(1);

docs/recipes/release-workflow/pre-releases.md

@@ -62,7 +62,7 @@ The Git history of the repository is now:
 
 We now decide to work on another future major release, in parallel of the beta one, which will also be composed of multiple features, some of them being breaking changes.
 
-To implement that workflow we can create the branch `alpha` from the branch `beta` and commit our first feature there. When pushing that commit, **semantic-release** will publish the pre-release version `3.0.0-alpha.1` on the dist-tag `@alpha`. That allow us to run integration tests by installing our module with `npm install example-module@alpha`. Other users installing with `npm install example-module` will still receive the version `1.0.0`.
+To implement that workflow we can create the branch `alpha` from the branch `beta` and commit our first feature there. When pushing that commit, **semantic-release** will publish the pre-release version `3.0.0-alpha.1` on the dist-tag `@alpha`. That allow us to run integration tests by installing our module with `npm install example-module@alpha`. Other users installing with `npm install example-module` will still receive the version `1.0.1`.
 
 The Git history of the repository is now:
 

docs/usage/workflow-configuration.md

@@ -12,7 +12,7 @@ See [Release workflow recipes](../recipes/release-workflow/README.md#release-wor
 The release workflow is configured via the [branches option](./configuration.md#branches) which accepts a single or an array of branch definitions.
 Each branch can be defined either as a string, a [glob](https://github.com/micromatch/micromatch#matching-features) or an object. For string and glob definitions each [property](#branches-properties) will be defaulted.
 
-A branch can defined as one of three types:
+A branch can be defined as one of three types:
 
 - [release](#release-branches): to make releases on top of the last version released
 - [maintenance](#maintenance-branches): to make releases on top of an old release

lib/plugins/utils.js

@@ -52,14 +52,12 @@ export async function loadPlugin({ cwd }, name, pluginsPath) {
     ? dirname(resolveFrom.silent(__dirname, pluginsPath[name]) || resolveFrom(cwd, pluginsPath[name]))
     : __dirname;
 
-  // See https://github.com/mysticatea/eslint-plugin-node/issues/250
   if (isFunction(name)) {
     return name;
   }
 
-  const { default: cjsExport, ...esmNamedExports } = await import(
-    resolveFrom.silent(basePath, name) || resolveFrom(cwd, name)
-  );
+  const file = resolveFrom.silent(basePath, name) || resolveFrom(cwd, name);
+  const { default: cjsExport, ...esmNamedExports } = await import(`file://${file}`);
 
   if (cjsExport) {
     return cjsExport;