Git Product home page Git Product logo

npm's Introduction

@semantic-release/npm

semantic-release plugin to publish a npm package.

Build Status npm latest version npm next version npm beta version

Step Description
verifyConditions Verify the presence of the NPM_TOKEN environment variable, or an .npmrc file, and verify the authentication method is valid.
prepare Update the package.json version and create the npm package tarball.
addChannel Add a release to a dist-tag.
publish Publish the npm package to the registry.

Install

$ npm install @semantic-release/npm -D

Usage

The plugin can be configured in the semantic-release configuration file:

{
  "plugins": ["@semantic-release/commit-analyzer", "@semantic-release/release-notes-generator", "@semantic-release/npm"]
}

Configuration

npm registry authentication

The npm token authentication configuration is required and can be set via environment variables.

Automation tokens are recommended since they can be used for an automated workflow, even when your account is configured to use the auth-and-writes level of 2FA.

npm provenance

If you are publishing to the official registry and your pipeline is on a provider that is supported by npm for provenance, npm can be configured to publish with provenance.

Since semantic-release wraps the npm publish command, configuring provenance is not exposed directly. Instead, provenance can be configured through the other configuration options exposed by npm. Provenance applies specifically to publishing, so our recommendation is to configure under publishConfig within the package.json.

npm provenance on GitHub Actions

For package provenance to be signed on the GitHub Actions CI the following permission is required to be enabled on the job:

permissions:
  id-token: write # to enable use of OIDC for npm provenance

It's worth noting that if you are using semantic-release to its fullest with a GitHub release, GitHub comments, and other features, then more permissions are required to be enabled on this job:

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
  id-token: write # to enable use of OIDC for npm provenance

Refer to the GitHub Actions recipe for npm package provenance for the full CI job's YAML code example.

Environment variables

Variable Description
NPM_TOKEN Npm token created via npm token create

Options

Options Description Default
npmPublish Whether to publish the npm package to the registry. If false the package.json version will still be updated. false if the package.json private property is true, true otherwise.
pkgRoot Directory path to publish. .
tarballDir Directory path in which to write the package tarball. If false the tarball is not be kept on the file system. false

Note: The pkgRoot directory must contain a package.json. The version will be updated only in the package.json and npm-shrinkwrap.json within the pkgRoot directory.

Note: If you use a shareable configuration that defines one of these options you can set it to false in your semantic-release configuration in order to use the default value.

npm configuration

The plugin uses the npm CLI which will read the configuration from .npmrc. See npm config for the option list.

The registry can be configured via the npm environment variable NPM_CONFIG_REGISTRY and will take precedence over the configuration in .npmrc.

The registry and dist-tag can be configured under publishConfig in the package.json:

{
  "publishConfig": {
    "registry": "https://registry.npmjs.org/",
    "tag": "latest"
  }
}

Notes:

  • The presence of an .npmrc file will override any specified environment variables.
  • The presence of registry or dist-tag under publishConfig in the package.json will take precedence over the configuration in .npmrc and NPM_CONFIG_REGISTRY

Examples

The npmPublish and tarballDir option can be used to skip the publishing to the npm registry and instead, release the package tarball with another plugin. For example with the @semantic-release/github plugin:

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    [
      "@semantic-release/npm",
      {
        "npmPublish": false,
        "tarballDir": "dist"
      }
    ],
    [
      "@semantic-release/github",
      {
        "assets": "dist/*.tgz"
      }
    ]
  ]
}

When publishing from a sub-directory with the pkgRoot option, the package.json and npm-shrinkwrap.json updated with the new version can be moved to another directory with a postversion. For example with the @semantic-release/git plugin:

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    [
      "@semantic-release/npm",
      {
        "pkgRoot": "dist"
      }
    ],
    [
      "@semantic-release/git",
      {
        "assets": ["package.json", "npm-shrinkwrap.json"]
      }
    ]
  ]
}
{
  "scripts": {
    "postversion": "cp -r package.json .. && cp -r npm-shrinkwrap.json .."
  }
}

npm's People

Contributors

alexanderbabel avatar antongolub avatar blaky avatar c0zen avatar danez avatar dependabot[bot] avatar dominykas avatar domoritz avatar drapegnik avatar fes300 avatar gr2m avatar greenkeeper[bot] avatar hamzahamidi avatar hershmire avatar jameshartig avatar jquense avatar kevin-cho avatar kleinfreund avatar lirantal avatar oscard0m avatar pathurs avatar pvdlg avatar renovate[bot] avatar roggervalf avatar rxgx avatar ryaninvents avatar sapegin avatar swain avatar travi avatar welingtonms avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

npm's Issues

*d.ts files are not published

package.json

"main": "./lib/index.js",
"module": "./lib/index.es.js",
"types": "lib/index.d.ts",

.releaserc

{
  "plugins": [
    ["@semantic-release/commit-analyzer", {
      "preset": "angular",
      "releaseRules": [
        { "type": "docs", "release": "patch" },
        { "type": "refactor", "release": "patch" },
        { "type": "style", "release": "patch" },
        { "type": "chore", "release": "patch" },
        { "type": "build", "release": "patch" },
        { "type": "ci", "release": "patch" }
      ]
    }],
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    "@semantic-release/npm",
    ["@semantic-release/git", {
      "assets": ["lib/**/*.{js,ts,css}", "CHANGELOG.md", "package.json"]
    }]
  ]
}

ui-library [local]

image

ui-library [node_modules]
image

How do I include ts files in my npm build? I thought that "assets": ["lib/**/*.{js,ts,css}", "CHANGELOG.md", "package.json"] will do the trick.

getLastRelease: Allow customizing git tag fallback format

As of 2.6.1, the getLastRelease plugin can only be used if the git tag format is either 1.2.3 or v1.2.3. This makes it incompatible with semantic-release-monorepo, which had been using the output of this plugin, only replaced gitHead with its own lookup using the format my-package-v1.2.3. (As an aside, I'm surprised this isn't a breaking change since the output of the plugin has changed).

As we've been over before, I understand that supporting this type of configuration isn't a goal of semantic-release. We've been happy to work around some of the limitations and it's been working great! However, some of the recent changes to semantic-release and its core plugins have made it more difficult and with this change I unfortunately don't see a workaround at all.

Ultimately, we're hoping to avoid having to create a duplicate version of each common semantic-release plugin (e.g. semantic-release-monorepo/npm, semantic-release-monorepo/github, etc) only to make some minor tweak.

What are your thoughts?

An in-range update of npm is breaking the build 🚨

The dependency npm was updated from 6.5.0 to 6.6.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

npm is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 97 commits.

There are 97 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Preserve `package.json` formatting

Using readJson and writeJson from fs-extra remove the JSON formatting and write the package.json as one long string.

It's a problem for plugins like git that publish the pacakge.json

An in-range update of semantic-release is breaking the build 🚨

Version 15.9.3 of semantic-release was just published.

Branch Build failing 🚨
Dependency semantic-release
Current Version 15.9.2
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

semantic-release is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

Release Notes v15.9.3

15.9.3 (2018-07-31)

Bug Fixes

  • do not hide env variable value if shorter than 5 (b082a2e)
Commits

The new version differs by 1 commits.

  • b082a2e fix: do not hide env variable value if shorter than 5

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Security vulverabilities from "tar" and "fstream"

I am using semantic-release ^15.13.16 as a devDependency, when run npm audit I get:

found 12 high severity vulnerabilities

All from semantic-release/npm, from "tar" and "fstream" packages.

In my package-lock.json I have:

... "@semantic-release/npm": { "version": "5.1.10", ...

how to publish @org scoped public packages

I am unable to publish a org scored package

@kronos-integration/test-step
402\nnpm ERR! code E402\nnpm ERR! You must sign up for private packages : @kronos-integration/test-step\n\nnpm ERR! A complete log of this run can be found in:\nnpm ERR!     /home/travis/.npm/_logs/2018-01-05T21_04_12_179Z-debug.log\n',
  failed: true,

is there a way to configure the equivalent of:

npm publish --access public

version or tag

Hi,

i use semantic-release to generate release candidate (RC) and release.
When i release (RC or not), i want to update version in package.json.

Problem : I make a release candidate, i specify a tagFormat v{version}-RC but package.json is updated with version (no version-RC).

Is-it a bug or the appropriate behavior ?

Regards,

An in-range update of nock is breaking the build 🚨

Version 9.1.6 of nock was just published.

Branch Build failing 🚨
Dependency nock
Current Version 9.1.5
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

nock is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build failed Details

Release Notes v9.1.6

9.1.6 (2018-01-08)

Bug Fixes

  • implement callback on req.write and req.end. (#1047) (cb20aa1)
Commits

The new version differs by 2 commits.

  • 573b42b chore: remove executable bit from interceptor.js. (#1045)
  • cb20aa1 fix: implement callback on req.write and req.end. (#1047)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

FYI: npm publish errors

This somewhat of an FYI regarding an npm bug that impacts semantic-release.

Current behavior

An npm bug (it seems) is causing partial semantic release publishes

Expected behavior

I'm not sure whether it's appropriate for semantic-release to implement a workaround for this, but ideally it would continue with the release somehow.

Environment

Using latest semantic-release on TravisCI, and I'm seeing this same problem: npm/npm#20787

The result is:

  1. The release notes are not published to GitHub when it first fails
  2. The next runs attempts to publish "over the top" and gets rejected for duplicate version

An in-range update of sinon is breaking the build 🚨

Version 4.1.4 of sinon was just published.

Branch Build failing 🚨
Dependency sinon
Current Version 4.1.3
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build failed Details

Release Notes Minor fix for Symbol names and deprecation of spy.reset
  • Fix: assertion error messages did not handle Symbol names (#1640)
  • Deprecate spy.reset(), use spy.resetHistory() instead (#1446)
Commits

The new version differs by 36 commits.

  • 1ea2749 Update docs/changelog.md and set new release id in docs/_config.yml
  • 078c082 Add release documentation for v4.1.4
  • 571263e 4.1.4
  • f2ee9f1 Update History.md and AUTHORS for new release
  • a8262dd Assertion error messages handle symbolic method names
  • 8fa1e14 Merge pull request #1641 from mroderick/point-to-stack-overflow
  • 7c1ebd0 Update issue links to point to sinonjs/sinon
  • 93418f6 Update documentation to emphasize Stack Overflow
  • ca9e2fa Merge pull request #1636 from fearphage/fix-headless-chrome-in-circle
  • 39186f4 use google-chrome-unstable for tests
  • 6315621 invalidate cache
  • d078af9 try using default chrome install
  • 177c4b6 upgraded to the lastest official version of mochify
  • ecdc4e0 test with updated mochify
  • 360c2e7 added more details and notes

There are 36 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

No way to configure that we should always authenticate to NPM

My scenario is that our NPM server is a locally-running Artifactory instance and every interaction with is requires authentication - even reads. I'm getting a 403 during the call to get the last release. This call configures the npm client with the auth property, but does not set alwaysAuth: true and does not provide a way for me to configure this plugin to do that. I've tested it locally and adding that option solves my issue.

I assume that we don't want to set always set that to true for all users, but at least providing a way to configure this plugin to operate in that mode would help me. I could start working on a pull request if you think adding this is the right thing to do. Thanks.

getLastRelease: Find latest version irregardless of dist-tag

To my understanding, there can only be one version of a package on npm. It isn't possible to release the same version under multiple dist-tags, rather dist-tags are associated with a particular version.

Assuming I'm not misunderstanding the above, I think getLastRelease returns the wrong result in some cases.

Let's assume npm show returns the following for a package:

{
  'dist-tags': { latest: '1.0.0', next: '2.0.1' },
  versions: [ '1.0.0', '2.0.0', '2.0.1' ],
}

If we run getLastRelease with the dist-tag latest, it will say the most recent version is 1.0.0, which isn't true. If analyzeCommits then returns "major", semantic-release will try to release version 2.0.0 and will fail because that version has already been published.

I believe getLastRelease should always return 2.0.1 in this scenario, regardless of what dist-tag is configured.

An in-range update of ava is breaking the build 🚨

The devDependency ava was updated from 1.2.1 to 1.3.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

ava is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Release Notes for 1.3.0

Bug fixes

  • We've fixed a rather embarrasing bug with t.throws() and t.throwsAsync(). If you'd set a code expectation to a number we never actually checked that the thrown error had such a code! Thanks to @qlonik for both spotting and fixing this. 82daa5e
  • 1.2.0 contained a regression which meant that if you faked clearTimeout(), you'd break AVA. That's now been fixed. 40f331c
  • Snapshot files are now recognized as source files, so if you're using watch mode and you delete one, AVA won't rerun all your test files. d066f6f

New features

You can now use require() in ava.config.js files to load non-ES modules. 334e15b

All changes

v1.2.1...v1.3.0

Thanks

Thank you @itaisteinherz, @jdalton, @kagawagao, @KompKK, @SleeplessByte, @Chrisyee22 and @qlonik for helping us with this release. We couldn't have done this without you!

Get involved

We welcome new contributors. AVA is a friendly place to get started in open source. We have a great article on getting started contributing and a comprehensive contributing guide.

Commits

The new version differs by 12 commits.

  • b0fadb4 1.3.0
  • 9600966 Bump dependencies
  • 82daa5e Assert on expected error code, even when a number
  • 1e3b072 Document timeout configuration
  • d97f11d Improve pronunciation examples
  • 40f331c Fix unbound reference to clearTimeout
  • 334e15b Support require() in config files
  • 5751226 Added few tests for lib/chalk.js
  • 7d10446 Fix link to Babel recipe
  • 565822e Update esm package detection
  • 2fce19f Remove the typings field in package.json
  • d066f6f Recognize snapshot files as source files

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of fs-extra is breaking the build 🚨

Version 4.0.3 of fs-extra was just published.

Branch Build failing 🚨
Dependency fs-extra
Current Version 4.0.2
Type dependency

This version is covered by your current version range and after updating it in your project the build failed.

fs-extra is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build failed Details

Commits

The new version differs by 10 commits.

  • bd3376b 4.0.3
  • f934357 Merge pull request #520 from arcanis/patch-1
  • d21da93 Fixes fs-extra on linux
  • a6e8cd6 Add issue template (#514)
  • 2599b67 Merge pull request #501 from jprichardson/rimraf-backports
  • ddb5cb4 Use octal notation for chmod values in rimraf.js
  • cc6d425 Merge pull request #500 from revelt/patch-1
  • d416fa7 typo fixed
  • 41a33c2 Merge pull request #497 from nico29/docs/copy-improvements
  • 4f01664 docs: update copy to show differences with cp

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Package version update changes code styling

First of all, thanks for creating these tools. I recently started using it for some of my projects, and I love it. Unfortunately I saw something I did not like, it changes the code styling when you use an other style instead of 2 spaces. Personally, I think that commits like this one can and should be avoided. Luckily there is a package out there that can detect a used indentation, detect-indent.

I also created a plugin for semantic releases to manage Expo release updates. In this library I used detect indent to use the original indentation of the file instead of a hardcoded version, you can see this happening here. If you want I can create a PR to create a first draft of an implementation.

Cheers,
Cedric

Define registry and tag into plugin config?

I'm using semantic-release-monorepo and I'd like to share the same publishConfig across all my packages.

Right now I have to define:

"publishConfig": {
  "registry": "my custom registry",
  "tag": "latest"
}

on each package.
It would be useful to have the ability to define the registry and tag properties in the plugin config so that they will be shared by all the packages.

Example:

  "release": {
    "publish": [
      {
        "path": "@semantic-release/npm",
        "registry": "registry here",
        "tag": "latest"
      }
    ],
  }

Version number updated in package.json and package-lock.json instead of package.json in pkgRoot

Versions

semantic-release: 15.1.7
@semantic-release/npm: 3.2.4

Configuration

"release": {
    "noCi": true,
    "tagFormat": "${version}",
    "publish": [
      {
        "path": "@semantic-release/npm",
        "pkgRoot": "dist"
      }
    ]
  }

Description

I have an Angular repository where I would like to use semantic-release to maintain the version number of the library. However I have not succeeded using this package, yet. My build system compiles the source code to the ./dist folder, which is the code that needs to be published.

As the documentation declares, the script should determine the next version number based on the commit messages and write this version number to the package.json in the provided pkgRoot folder.

However, unexpectedly, at the end of the release process - currently I'm trying to release from my computer not from CI to have a better debugging experience - the version number of the package.json in the dist folder remains untouched and the package.json and package-lock.json files in the root folder are updated with the new version number.

At the end of a process like this, I am ended up with a situation where I have a "successfully" released version on GitHub and an NPM release with an incorrect version number.

I am really happy to share more data about my issue, but I feel lost in this situation.

Restore `.npmrc` to its original state

The plugin create a local .npmrc file for authentication.
After each step (verifyConditions, prepare, publish, addChannel) we should restore the local .npmrc to its original state:

  • If there was no .npmrc file we should delete the one we have created
  • If there was a .npmrc file we should restore it

See semantic-release/semantic-release#1109

An in-range update of nock is breaking the build 🚨

Version 9.3.2 of nock was just published.

Branch Build failing 🚨
Dependency nock
Current Version 9.3.1
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

nock is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Release Notes v9.3.2

9.3.2 (2018-06-07)

Bug Fixes

Commits

The new version differs by 1 commits.

  • b5b40c1 fix: restore compatibility with Node <4.5 (#1144)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Package does not appear to execute npm hooks like `prepack`

There's lots of context below, but the major thing here is my package leverages npm's prepack hook to create the dist/ dir with all of my generated assets. Locally, running npm pack, the tarball that's created includes that dist/ dir, however when publishing my package via @semantic-release/npm the prepack script does not appear to run, and the published package does not include the dist/ dir.

Relevant dependencies

    "@semantic-release/exec": "^2.3.0",
    "@semantic-release/git": "^7.0.0",
    "@semantic-release/gitlab": "^2.1.4",
    "semantic-release": "^15.9.3",

Scripts:

Especially relevant to note the prepack script runs the build script

  "scripts": {
    "build": "gulp build --production && ls -la",
    "dev": "gulp",
    "lint": "gulp lint-css",
    "security": "nsp check --output checkstyle",
    "start": "npm run build",
    "test": "npm run lint",
    "prepack": "npm run build",
    "precommit": "sh scripts/verify-files.sh",
    "commitmsg": "commitlint -E GIT_PARAMS",
    "next_release:prepare_readme": "sh scripts/prepare-readme.sh",
    "next_release:version": "node scripts/next-release-version.js",
    "next_release:changelog": "standard-changelog",
    "next_release:publish": "npx semantic-release",
    "next_release": "npm run next_release:version -s"
  }

Releaserc file

{
    "branch": "master",
    "repository": "...",
    "verifyConditions": [],
    "prepare": [
      "@semantic-release/npm",
      {
        "path": "@semantic-release/exec",
        "cmd": "./scripts/prepare-readme.sh",
      },
      {
        "path": "@semantic-release/git",
        "assets": ["package.json", "package-lock.json", "README.md"],
        "message": "chore(release): Release ${nextRelease.version}\n\n${nextRelease.notes}"
      }
    ],
    "publish": [
      "@semantic-release/npm",
      "@semantic-release/gitlab"
    ],
    "success": false,
    "fail": false,
    "debug": true
}

Relevant step in .gitlabci.yml file

NPM Publish:
  stage: publish
  image: $my_image
  script:
    - npm i
    - npm run next_release:publish
  only:
    - master

For reference, build output when run locally:

$npm pack

> @uitk/[email protected] prepack /Users/com4592/Projects/git/fx-uitk/ui-toolkit
> npm run build


> @uitk/[email protected] build /Users/com4592/Projects/git/fx-uitk/ui-toolkit
> gulp build --production && ls -la

[19:17:40] Failed to load external module @babel/register
[19:17:40] Requiring external module babel-register
[19:17:42] Using gulpfile ~/Projects/git/fx-uitk/ui-toolkit/gulpfile.babel.js
[19:17:42] Starting 'build'...
[19:17:42] Starting 'clean'...
[19:17:42] Finished 'clean' after 2.92 ms
[19:17:42] Starting 'iconFonts'...
[19:17:42] Starting 'svgIcons'...
[19:17:42] Finished 'svgIcons' after 598 ms
[19:17:43] gulp-svgicons2svgfont: Font created
[19:17:43] Finished 'iconFonts' after 1.2 s
[19:17:43] Starting 'styleGuide'...
[19:17:43] Starting 'sass'...
[19:17:43] Starting 'javascript'...
[19:17:43] Starting 'javascriptThemes'...
[19:17:43] Starting 'images'...
[19:17:43] Starting 'copy'...
[19:17:48] Finished 'styleGuide' after 5.24 s
[19:18:10] Finished 'javascript' after 27 s
[19:18:15] Finished 'javascriptThemes' after 32 s
[19:18:15] gulp-imagemin: Minified 54 images (saved 1.58 MB - 51.4%)
[19:18:16] Finished 'sass' after 33 s
[19:18:16] Finished 'images' after 33 s
[19:18:16] Finished 'copy' after 33 s
[19:18:16] Starting 'copyFonts'...
[19:18:16] Finished 'copyFonts' after 34 ms
[19:18:16] Starting 'pages'...
[19:18:16] Finished 'pages' after 350 ms
[19:18:16] Finished 'build' after 34 s
total 1672
uitk-ui-toolkit-2.1.7.tgz

Contents of uitk-ui-toolkit-2.1.7.tgz

CHANGELOG.md
README.md
dist
gulpfile.babel.js
node_modules
package.json
src```

## CI Publish step output:
```txt
Running with gitlab-runner 10.6.0 (a3543a27)
  on ip-10-247-90-186 460123f3

$ export BUILD_CONTEXT=gitlab
$ npm i

> [email protected] install /builds/fx-uitk/ui-toolkit/node_modules/phantomjs-prebuilt
> node install.js

PhantomJS not found on PATH
Downloading https://github.com/Medium/phantomjs/releases/download/v2.1.1/phantomjs-2.1.1-linux-x86_64.tar.bz2
Saving to /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2
Receiving...

Received 22866K total.
Extracting tar contents (via spawned process)
Removing /builds/fx-uitk/ui-toolkit/node_modules/phantomjs-prebuilt/lib/phantom
Copying extracted folder /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2-extract-1533337076207/phantomjs-2.1.1-linux-x86_64 -> /builds/fx-uitk/ui-toolkit/node_modules/phantomjs-prebuilt/lib/phantom
Writing location.js file
Done. Phantomjs binary available at /builds/fx-uitk/ui-toolkit/node_modules/phantomjs-prebuilt/lib/phantom/bin/phantomjs

> node scripts/install.js

Downloading binary from https://github.com/sass/node-sass/releases/download/v4.9.2/linux_musl-x64-57_binding.node
Download complete
Binary saved to /builds/fx-uitk/ui-toolkit/node_modules/node-sass/vendor/linux_musl-x64-57/binding.node
Caching binary to /root/.npm/node-sass/4.9.2/linux_musl-x64-57_binding.node

> [email protected] install /builds/fx-uitk/ui-toolkit/node_modules/husky
> node ./bin/install.js

husky
CI detected, skipping Git hooks installation

> [email protected] postinstall /builds/fx-uitk/ui-toolkit/node_modules/svgicons2svgfont
> npm run metapak --silent

sh: metapak: not found

> [email protected] postinstall /builds/fx-uitk/ui-toolkit/node_modules/node-sass
> node scripts/build.js

Binary found at /builds/fx-uitk/ui-toolkit/node_modules/node-sass/vendor/linux_musl-x64-57/binding.node
Testing binary
Binary is fine

> [email protected] postinstall /builds/fx-uitk/ui-toolkit/node_modules/gifsicle
> node lib/install.js

  ⚠ spawn /builds/fx-uitk/ui-toolkit/node_modules/gifsicle/vendor/gifsicle ENOENT
  ⚠ gifsicle pre-build test failed
  ℹ compiling from source
  ✔ gifsicle built successfully

> [email protected] postinstall /builds/fx-uitk/ui-toolkit/node_modules/jpegtran-bin
> node lib/install.js

  ⚠ spawn /builds/fx-uitk/ui-toolkit/node_modules/jpegtran-bin/vendor/jpegtran ENOENT
  ⚠ jpegtran pre-build test failed
  ℹ compiling from source
  ✔ jpegtran built successfully

> [email protected] postinstall /builds/fx-uitk/ui-toolkit/node_modules/optipng-bin
> node lib/install.js

  ⚠ spawn /builds/fx-uitk/ui-toolkit/node_modules/optipng-bin/vendor/optipng ENOENT
  ⚠ optipng pre-build test failed
  ℹ compiling from source
  ✔ optipng built successfully
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

added 2209 packages in 102.399s

> @uitk/[email protected] next_release:publish /builds/fx-uitk/ui-toolkit
> npx semantic-release

[22:59:56] [semantic-release] › ℹ  Running semantic-release version 15.9.2
[22:59:56] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[22:59:56] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
[22:59:56] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/npm"
[22:59:56] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/exec"
[22:59:56] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/git"
[22:59:56] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/npm"
[22:59:56] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/gitlab"
[22:59:56] [semantic-release] › ✔  Run automated release from branch master
[22:59:58] [semantic-release] › ✔  Allowed to push to the Git repository
[23:00:00] [semantic-release] › ℹ  Found git tag v2.1.6 associated with version 2.1.6
[23:00:00] [semantic-release] › ℹ  Found 1 commits since last release
[23:00:00] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[23:00:00] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: fix: different output for bugs
[23:00:00] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[23:00:00] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analysis of 1 commits complete: patch release
[23:00:00] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[23:00:00] [semantic-release] › ℹ  The next release version is 2.1.7
[23:00:00] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[23:00:00] [semantic-release] › ✔  Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[23:00:00] [semantic-release] › ℹ  Start step "prepare" of plugin "@semantic-release/npm"
[23:00:00] [semantic-release] [@semantic-release/npm] › ℹ  Verify authentication for registry https://<self-hosted-npm-reg>/
[23:00:00] [semantic-release] [@semantic-release/npm] › ℹ  Wrote version 2.1.7 to /builds/fx-uitk/ui-toolkit/package.json
[23:00:00] [semantic-release] [@semantic-release/npm] › ℹ  Wrote version 2.1.7 to /builds/fx-uitk/ui-toolkit/package-lock.json
[23:00:00] [semantic-release] › ✔  Completed step "prepare" of plugin "@semantic-release/npm"
[23:00:00] [semantic-release] › ℹ  Start step "prepare" of plugin "@semantic-release/exec"
[23:00:00] [semantic-release] [@semantic-release/exec] › ℹ  Call script ./scripts/prepare-readme.sh
Generating Readme for v2.1.7
Readme generated, you will want to commit this change
[23:00:00] [semantic-release] › ✔  Completed step "prepare" of plugin "@semantic-release/exec"
[23:00:00] [semantic-release] › ℹ  Start step "prepare" of plugin "@semantic-release/git"
[23:00:00] [semantic-release] [@semantic-release/git] › ℹ  Found 3 file(s) to commit
[23:00:05] [semantic-release] [@semantic-release/git] › ℹ  Prepared Git release: v2.1.7
[23:00:05] [semantic-release] › ✔  Completed step "prepare" of plugin "@semantic-release/git"
[23:00:05] [semantic-release] › ℹ  Call plugin generateNotes
[23:00:05] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[23:00:05] [semantic-release] › ✔  Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[23:00:08] [semantic-release] › ✔  Created tag v2.1.7
[23:00:08] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/npm"
[23:00:08] [semantic-release] [@semantic-release/npm] › ℹ  Verify authentication for registry https://<self-hosted-npm-reg>/
[23:00:08] [semantic-release] [@semantic-release/npm] › ℹ  Publishing version 2.1.7 to npm registry
[23:00:55] [semantic-release] [@semantic-release/npm] › ℹ  Published @uitk/[email protected] on https://<self-hosted-npm-reg>/
[23:00:55] [semantic-release] › ✔  Completed step "publish" of plugin "@semantic-release/npm"
[23:00:55] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/gitlab"
[23:00:55] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://<self-hosted-gitlab-env>)
[23:00:55] [semantic-release] [@semantic-release/gitlab] › ℹ  Published GitLab release: v2.1.7
[23:00:55] [semantic-release] › ✔  Completed step "publish" of plugin "@semantic-release/gitlab"
[23:00:55] [semantic-release] › ✔  Published release 2.1.7
Job succeeded

Contents of published package:

$ls -A1
CHANGELOG.md
README.md
gulpfile.babel.js
node_modules
package.json
src

@semantic-release/npm is being loaded by default

Hi,

I am trying to set up semantic release to my repo but I don't want to push to npm after success, so I removed @semantic-release/npm from my package.json but when I do a dry run a and a run in CI environment @semantic-release/npm is being loaded and packaged is being published to npm

Screenshot 2019-03-13 at 12 43 54 PM

Screenshot 2019-03-13 at 12 43 34 PM

Bug Report: Explicit dependency on npm?

Why this is a problem: Requiring npm breaks our npm ci since npm is incapable of writing itself correctly to the package-lock.json file (this is a bug with them apparently - it fails complaining that cached packages are not cached).

This prevents us from updating semantic-release.

Why do we need an explicit npm dependency here? Is this really necessary? I don't think it's standard practise either (at least I've never seen it anywhere).

Thanks for all your hard work! Cheer, L~

Edit: My preference would be to fail on run rather than to always require it as a package dependency.
That way we can globally install the npm version when semantic-release is required to run. But it's not always required to be installed.

Publish RC version

I'm wondering if this package supports RC releases. For example, how I can set the next publish to be:
2.0.0-rc.0

Can't find anything in the documentation.
Thanks.

ENONPMTOKEN When npmPublish is false

Config is

  "release": {
    "verifyConditions": ["@semantic-release/git", "@semantic-release/github"],
    "getLastRelease": "@semantic-release/git",
    "publish": [{
        "path": "@semantic-release/npm",
        "npmPublish": false
      }, 
      "@semantic-release/git", 
      "@semantic-release/github"
    ]
  }

Error is raised

[Semantic release]: Call plugin publish
[Semantic release]: Verify authentication for registry https://registry.npmjs.org/
[Semantic release]: ENONPMTOKEN No npm token specified.

On my point of view, if npmPublish is set to false, there is not need to authentificate on npm. Am i missing something ?

Error: package.json requires a valid "version" field

This seems to be introduces by the patch in #22. If my package.json doesn't contain a version field, I'm not able to publish it to npm.
Using a placeholder like 0.0.0-development as I see it in this repository solves this, but is this actually the intended usage?

Check package permission on the registry

Currently we only check if the user is authenticated on the configured registry.
But if a user set a validNPM_TOKEN, that doesn't have the permission to deploy the current package the release will fail during the publish phase. Similarly if the package name is already taken the release will fail.

To avoid that we should check in the verifyConditions if the package exists, and if it does, make sure the user has read-write access to the package.
Unfortunately the npm-registry-client doesn't implement the method. So it would have to be done with npm access ls-collaborators <@scope/package>.

In addition it would be great, in case of a restricted package to be able to check if the organization is private and paid. But I'm didn't find a way to do that.
During publish if the organization is not private and paid, the registry returns a 402 error.

An in-range update of nock is breaking the build 🚨

Version 9.4.4 of nock was just published.

Branch Build failing 🚨
Dependency nock
Current Version 9.4.3
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

nock is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

Release Notes v9.4.4

9.4.4 (2018-07-31)

Bug Fixes

Commits

The new version differs by 3 commits.

  • 907be86 fix(#1076): allowUnmocked: true + host regex (#1179)
  • 8f0912a docs: Add CHANGELOG file pointing to GitHub releases
  • 15a472f build(#1169): remove glob and istanbul

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Publishing from "dist" and missing package.json

Hi,

I am trying to publish from a subdirectory named dist. I have the following plugin configured.

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

I, of course, get an error about the missing package.json as it doesn't exist there.

[9:13:33 AM] [semantic-release] › ✖  ENOPKG Missing `package.json` file.
A package.json file (https://docs.npmjs.com/files/package.json) at the root of your project is required to release on npm.

Please follow the npm guideline (https://docs.npmjs.com/getting-started/creating-node-modules) to create a valid package.json file.

{ AggregateError:
    SemanticReleaseError: Missing `package.json` file.

I tried adding a lifetime hook to force a copy first but it didn't work. This is what I tried

    "postversion": "cp package.json dist"

I am probably using the wrong lifetime hook ?

Is there a correct way to do this ?

Thanks in advance

Version 5.1.5 and above has not been published to npm registry

When trying to update semantic-release to the latest version to resolve some vulnerabilities I found that @semantic-release/npm has not been publishing releases to npm. These are all introduced by the npm module which was updated in version 5.1.5, the first version not to be published.

───────────────┬──────────────────────────────────────────────────────────────┐
│ high          │ Arbitrary File Overwrite                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ tar                                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.4.2                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ semantic-release                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ semantic-release > @semantic-release/npm > npm > libcipm >   │
│               │ npm-lifecycle > node-gyp > tar                               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://www.npmjs.com/advisories/803                         │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ high          │ Arbitrary File Overwrite                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ tar                                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.4.2                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ semantic-release                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ semantic-release > @semantic-release/npm > npm > node-gyp >  │
│               │ tar                                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://www.npmjs.com/advisories/803                         │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ high          │ Arbitrary File Overwrite                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ tar                                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.4.2                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ semantic-release                                             │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ semantic-release > @semantic-release/npm > npm >             │
│               │ npm-lifecycle > node-gyp > tar                               │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://www.npmjs.com/advisories/803              

[Bug] plugin does not verify if package.json contain private: true

I have been hitting a case using npx semantic-release and this plugin.

The verify step went through, but during the npm release I ended up having an error:

npm ERR! This package has been marked as private
npm ERR! Remove the 'private' field from the package.json to publish it.

This result in an incomplete release exited with 1.

Can this be fixed somehow, It will save some "git revert" efforts.

This just bit me:

I just had a case where a user mistakenly didn't have public rights to the npm package (after changing tokens and using a different user for the token a couple weeks ago).

However, the verifyConditions didn't catch this. It was only caught when the npm publish step failed with a 403 error message stating the user doesn't have publish rights.

That meant the the git tag was still pushed to the repo, leaving the tag out of sync. Retrying the build would then not publish, because the tag was already pushed.

Originally posted by @felixfbecker in #4 (comment)

An in-range update of sinon is breaking the build 🚨

Version 4.1.6 of sinon was just published.

Branch Build failing 🚨
Dependency sinon
Current Version 4.1.5
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 10 commits.

  • 68c37ed Update docs/changelog.md and set new release id in docs/_config.yml
  • cd8ae51 Add release documentation for v4.1.6
  • 29e80be 4.1.6
  • a5c59a5 Update History.md and AUTHORS for new release
  • 0ae60b6 Merge pull request #1653 from mroderick/upgrade-dependencies
  • dcd4191 Upgrade browserify to latest
  • a316f02 Upgrade markdownlint-cli to latest
  • 78ebdb3 Upgrade lint-staged to latest
  • fcf967b Upgrade dependency supports-color
  • 7c3cb4f Enable StaleBot with default configuration (#1649)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

npmPublish setting ignored

Running the release skips publishing to npm because the private field is set to true, however, I have set npmPublish: true in .releaserc.

// .releaserc
{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/gitlab",
    "@semantic-release/changelog",
    ["@semantic-release/npm", {
      "npmPublish": true
    }],
    "@semantic-release/git"
  ]
}
# job output
# [snip]
[19:47:08] [semantic-release] [@semantic-release/npm] › ℹ  Skip publishing to npm registry as package.json's private property is true

Support npm `auth-and-writes` 2FA setting

Follow-up to #92.

It should be possible to support npm auth-and-writes level of two-factor-authentication by generating the OTP on the CI with a tool like otplib.

Users would have to enable npm 2FA via command line and on the step where the QRCode is displayed, copy the secret key displayed below it (Something like Or enter code: XXXXXXXX....).
The secret would have to be added on the CI as a secured environment variable (e.g. NPM_2FA_SECRET).

The only constraint is that if 2FA is already enabled, there is no way to retrieve the secret key. So users would have to disable 2FA and re-enable it via CLI to obtain a new secret key.

Then the plugin would generate the OTP with:

const {authenticator} = require('otplib');

const otp =authenticator.generate(process.env.NPM_2FA_SECRET);

And call npm publish with the --otp option.

We would also need to implement #11 and make sure that if the auth-and-writes option is enabled the environment variable NPM_2FA_SECRET is set. Unfortunately it doesn't seems there is a way to verify if NPM_2FA_SECRET is correct, as all the npm command that requires an OTP are things that makes changes server side, so we can't use them to test.

potential publish failure recovery improvement

just ran into an issue that i figured was at least worth raising visibility to.

we made a change that triggered semantic-release to publish a new version to npm, like normal, but the publish step report reported a failure, so semantic-release did not tag the commit or publish release notes. this makes sense since a failure in the publish step should mean that the package did not get published.

however, in this case the package did get successfully published even though the response to the publish call was an error. it looks like it was some sort of error reading the result of the publish from the npm cache servers or something. here is the error, for reference:

npm ERR! registry error parsing json
npm ERR! registry error parsing json
npm ERR! registry error parsing json
npm ERR! publish Failed PUT 503
npm ERR! Unexpected token < in JSON at position 1
npm ERR! 
npm ERR! <?xml version="1.0" encoding="utf-8"?>
npm ERR! <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
npm ERR!  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
npm ERR! <html>
npm ERR!   <head>
npm ERR!     <title>503 backend read error</title>
npm ERR!   </head>
npm ERR!   <body>
npm ERR!     <h1>Error 503 backend read error</h1>
npm ERR!     <p>backend read error</p>
npm ERR!     <h3>Guru Mediation:</h3>
npm ERR!     <p>Details: cache-dca17722-DCA 1519832230 264933137</p>
npm ERR!     <hr>
npm ERR!     <p>Varnish cache server</p>
npm ERR!   </body>
npm ERR! </html>
npm ERR! 

what i guess i'm wondering is if it might be worth checking npm info after a failure to confirm if the failure was an actual failure to publish or just a failure to report the successful publish. seems low priority since this should be very rare, but it would save needing to push a tag manually and building release notes manually (which i didnt bother to do since its not easy enough w/o semantic-release doing it for me) in the rare cases where it does happen.

Verify repository credentials only when publishing

Ok, so internally at Peakfijn we have a use case for this plugin. One that isn't supported right now, but I feel it might be worth to bring it up here.

We are mostly creating closed source projects. Ones that doesn't get "published" to the repository. However, we do sometimes use the version property loaded from the package file to use when debugging. Is it possible to only validate NPM repository credentials when this package is actually used for the publish hook? When this is only validated there, we can use it within the prepare hook and get our version updated without pushing to the repository. This change in the package file is then picked up and committed in our Git Branches plugin (a fork from semantic-release/git).

I'm not sure if this is even possible, I do think it is but I'm not sure. And maybe I'm all alone in this, but this would definitely help us!

Cheers,
Cedric

Bump npm dependency version to at least 6.6.0 (WARN deprecated [email protected])

Hi!

I'm using the latest version of semantic-release and upon running npm install I get the following warning:

npm WARN deprecated [email protected]: If using 2.x branch, please upgrade to at least 2.1.6 to avoid a serious bug with socket data flow and an import issue introduced in 2.1.0

According to npm list socks I get the following tree of dependencies:

my-project
└─┬ [email protected]
  └─┬ @semantic-release/[email protected]
    └─┬ [email protected]
      ├─┬ [email protected]
      │ └─┬ [email protected]
      │   └─┬ [email protected]
      │     └── [email protected] 
      └─┬ [email protected]
        └─┬ [email protected]
          └─┬ [email protected]
            └── [email protected] 

After a bit of research I found a commit for npm/cli which updates npm-registry-fetch to a version, which has [email protected] among it's dependencies and that commit was released right after [email protected] was released.

npm/cli@9cefcdc#diff-b9cfc7f2cdf78a7f4b91a753d10865a2

Please bump the version of npm to at least 6.6.0 to get that warning fixed.

Unable to get auth working against artifactory

I get a 401 when semantic-release tries to get the latest version of the package.

[Semantic release]: Call plugin get-last-release
info attempt registry request try #1 at 10:14:18
http request GET https://artifacts.schibsted.io/artifactory/api/npm/npm-virtual/@finn-no%2Ftest-semantic-release
http 401 https://artifacts.schibsted.io/artifactory/api/npm/npm-virtual/@finn-no%2Ftest-semantic-release
[Semantic release]: An error occurred while running semantic-release: { Error: Registry returned 401 for GET on https://artifacts.schibsted.io/artifactory/api/npm/npm-virtual/@finn-no%2Ftest-semantic-release

I set up auth like this: curl -u $ARTIFACTORY_USER:$ARTIFACTORY_PWD https://artifacts.schibsted.io/artifactory/api/npm/npm-virtual/auth/finn-no > .npmrc. I know this works as yarn right after it (which includes fetching dependencies only available on that Artifactory instance) succeeds.

I then do this (horribly inefficient, but it works):

- export NPM_TOKEN=""
- export NPM_PASSWORD=`node -p "require('npm-conf')().get('//artifacts.schibsted.io/artifactory/api/npm/npm-virtual/:_password');"`
- export NPM_USERNAME=`node -p "require('npm-conf')().get('//artifacts.schibsted.io/artifactory/api/npm/npm-virtual/:username');"`
- export NPM_EMAIL=`node -p "require('npm-conf')().get('//artifacts.schibsted.io/artifactory/api/npm/npm-virtual/:email');"`

in order to make the same auth available for semantic-release. (I have verified by cat that these variables are set).

Doing npm info against the same package after semantic-release gets 401 results in the expected 404 against the same url. So somehow auth is not provided to the npm plugin properly.

Any ideas on what's going wrong or how I can debug?

See semantic-release/travis-deploy-once#27 for previous discussion

setting tarballDir to CWD causes fs-extra error

After upgrading to fs-extra v8.0.0, fs-extra will throw an error whenever the "source" and "destination" paths are equal.

Error:

[2:37:29 AM] [semantic-release] › ✖  Failed step "prepare" of plugin "@semantic-release/npm"
[2:37:29 AM] [semantic-release] › ✖  An error occurred while running semantic-release: { Error: Source and destination must not be the same.
    at getStats (/home/travis/build/Colonise/[secure]/node_modules/fs-extra/lib/util/stat.js:82:17)
    at fs.stat (/home/travis/build/Colonise/[secure]/node_modules/fs-extra/lib/util/stat.js:40:16)
    at FSReqWrap.oncomplete (fs.js:154:5) pluginName: '@semantic-release/npm' }
{ Error: Source and destination must not be the same.
    at getStats (/home/travis/build/Colonise/[secure]/node_modules/fs-extra/lib/util/stat.js:82:17)
    at fs.stat (/home/travis/build/Colonise/[secure]/node_modules/fs-extra/lib/util/stat.js:40:16)
    at FSReqWrap.oncomplete (fs.js:154:5) pluginName: '@semantic-release/npm' }

Config:

{
    tarballDir: '.'
}

Error occurs at

await move(path.resolve(cwd, tarball), path.resolve(cwd, tarballDir.trim(), tarball));

Possible solution:
Check if tarballDir will actually change the output before calling move()
path.resolve(cwd, tarballDir.trim()) === path.resolve(cwd)

Set scope access on first publish

When publishing to a scope, the first release can specify --access public to turn the package under that scope public. Currently I just hack in the argument on my first CI run. Would be good to figure out a way to do this automatically.

Check if 2FA is enabled in verifyConditions

I don't know if this is an npm issue, but my publishes fail since I enabled 2FA. I wanted others to be aware of this

[Semantic release]: Publishing version 1.2.3 to npm registry
[Semantic release]: An error occurred while running semantic-release: { Error: Command failed: npm publish
npm ERR! publish Failed PUT 401
npm ERR! code E401
npm ERR! 404 You must provide a one-time pass. You can provide one using the "--otp" flag. : cli-highlight
npm ERR! 404 
npm ERR! 404  'cli-highlight' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/travis/.npm/_logs/2017-11-30T19_59_44_322Z-debug.log
    at Promise.all.then.arr (/home/travis/build/felixfbecker/cli-highlight/node_modules/@semantic-release/npm/node_modules/execa/index.js:236:11)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  code: 1,
  killed: false,
  stdout: '',
  stderr: 'npm ERR! publish Failed PUT 401\nnpm ERR! code E401\nnpm ERR! 404 You must provide a one-time pass. You can provide one using the "--otp" flag. : cli-highlight\nnpm ERR! 404 \nnpm ERR! 404  \'cli-highlight\' is not in the npm registry.\nnpm ERR! 404 You should bug the author to publish it (or use the name yourself!)\nnpm ERR! 404 \nnpm ERR! 404 Note that you can also install from a\nnpm ERR! 404 tarball, folder, http url, or git url.\n\nnpm ERR! A complete log of this run can be found in:\nnpm ERR!     /home/travis/.npm/_logs/2017-11-30T19_59_44_322Z-debug.log\n',
  failed: true,
  signal: null,
  cmd: 'npm publish',
  timedOut: false }
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] semantic-release: `semantic-release`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] semantic-release script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/travis/.npm/_logs/2017-11-30T19_59_44_346Z-debug.log
The command "npm run semantic-release" exited with 1.

npm 5.5.1

`npm version` hook support: preversion, version, postversion

This package uses a custom function to set the package.json version:

await updatePackageVersion(version, basePath, logger);

It does this instead of using npm version, likely because npm version does many undesirable things, but it seems our npm scripts are not being run. Our use case is we need to modify another file with the chosen version. Our scripts look like this:

  "scripts": {
    "sync-version": "sync-version package.json other-file",
    "version": "npm run sync-version && git add other-file",

Before, the version script would run during npm version, as documented.

With semantic-release, we're unsure how to do this. Right now, we are using @semantic-release/exec, but it would be nice to know which npm scripts are executed in which stages and which are not.

Private registry as an environment variable or plugin config

Hello,

The native NPM api uses the .npmrc file or publishConfig object from the package.json to set publishing configuration (registry, authentication...). I somehow disagree with this setup as I believe deployment configuration shouldn't be embedded in project files, but set at runtime in the CI environment.

You have done a great job at respecting NPM's API. I was wondering if it would be possible to be able to set the NPM registry directly in the plugin configuration or via an environment variable and use it in the --registry option of most NPM commands.

What is your take on this ? Would you consider it as an additional feature ?

All the best and thanks for the great plugin !

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.