Do not include @semantic-release/npm by default #1260

leethree · 2019-08-13T08:55:38Z

New feature motivation

@semantic-release/npm is a huge dependency because it depends on npm. It's installed by default with semantic-release but a lot of projects are not using it. But because semantic-release is installed locally, all of the following things have to be installed but not used.

Here's the dependency tree for it:

┬ @semantic-release/npm@5.2.0-beta.6
├── @semantic-release/error@2.2.0
├─┬ aggregate-error@2.2.0
│ ├── clean-stack@2.2.0
│ └── indent-string@3.2.0
├── execa@1.0.0
├── fs-extra@7.0.1
├── lodash@4.17.15
├── nerf-dart@1.0.0
├── normalize-url@4.3.0
├─┬ npm@6.5.0
│ ├── abbrev@1.1.1
│ ├── ansicolors@0.3.2
│ ├── ansistyles@0.1.3
│ ├── aproba@1.2.0
│ ├── archy@1.0.0
│ ├─┬ bin-links@1.1.2
│ │ ├── bluebird@3.5.3
│ │ ├── cmd-shim@2.0.2
│ │ ├── gentle-fs@2.0.1
│ │ ├── graceful-fs@4.1.15
│ │ └── write-file-atomic@2.3.0
│ ├── bluebird@3.5.3
│ ├── byte-size@4.0.3
│ ├─┬ cacache@11.2.0
│ │ ├── bluebird@3.5.3
│ │ ├── chownr@1.0.1
│ │ ├── figgy-pudding@3.5.1
│ │ ├── glob@7.1.3
│ │ ├── graceful-fs@4.1.15
│ │ ├── lru-cache@4.1.3
│ │ ├── mississippi@3.0.0
│ │ ├── mkdirp@0.5.1
│ │ ├── move-concurrently@1.0.1
│ │ ├── promise-inflight@1.0.1
│ │ ├── rimraf@2.6.2
│ │ ├── ssri@6.0.1
│ │ ├── unique-filename@1.1.0
│ │ └── y18n@4.0.0
│ ├── call-limit@1.1.0
│ ├── chownr@1.0.1
│ ├── ci-info@1.6.0
│ ├─┬ cli-columns@3.1.2
│ │ ├─┬ string-width@2.1.1
│ │ │ ├── is-fullwidth-code-point@2.0.0
│ │ │ └─┬ strip-ansi@4.0.0
│ │ │   └── ansi-regex@3.0.0
│ │ └─┬ strip-ansi@3.0.1
│ │   └── ansi-regex@2.1.1
│ ├─┬ cli-table3@0.5.0
│ │ ├── colors@1.1.2
│ │ ├── object-assign@4.1.1
│ │ └── string-width@2.1.1
│ ├─┬ cmd-shim@2.0.2
│ │ ├── graceful-fs@4.1.15
│ │ └── mkdirp@0.5.1
│ ├─┬ columnify@1.5.4
│ │ ├── strip-ansi@3.0.1
│ │ └─┬ wcwidth@1.0.1
│ │   └─┬ defaults@1.0.3
│ │     └── clone@1.0.4
│ ├─┬ config-chain@1.1.12
│ │ ├── ini@1.3.5
│ │ └── proto-list@1.2.4
│ ├── debuglog@1.0.1
│ ├── detect-indent@5.0.0
│ ├── detect-newline@2.1.0
│ ├─┬ dezalgo@1.0.3
│ │ ├── asap@2.0.6
│ │ └── wrappy@1.0.2
│ ├── editor@1.0.0
│ ├── figgy-pudding@3.5.1
│ ├── find-npm-prefix@1.0.2
│ ├─┬ fs-vacuum@1.2.10
│ │ ├── graceful-fs@4.1.15
│ │ ├── path-is-inside@1.0.2
│ │ └── rimraf@2.6.2
│ ├─┬ fs-write-stream-atomic@1.0.10
│ │ ├── graceful-fs@4.1.15
│ │ ├── iferr@0.1.5
│ │ ├── imurmurhash@0.1.4
│ │ └── readable-stream@2.3.6
│ ├─┬ gentle-fs@2.0.1
│ │ ├── aproba@1.2.0
│ │ ├── fs-vacuum@1.2.10
│ │ ├── graceful-fs@4.1.15
│ │ ├── iferr@0.1.5
│ │ ├── mkdirp@0.5.1
│ │ ├── path-is-inside@1.0.2
│ │ ├── read-cmd-shim@1.0.1
│ │ └── slide@1.1.6
│ ├─┬ glob@7.1.3
│ │ ├── fs.realpath@1.0.0
│ │ ├── inflight@1.0.6
│ │ ├── inherits@2.0.3
│ │ ├─┬ minimatch@3.0.4
│ │ │ └─┬ brace-expansion@1.1.11
│ │ │   ├── balanced-match@1.0.0
│ │ │   └── concat-map@0.0.1
│ │ ├── once@1.4.0
│ │ └── path-is-absolute@1.0.1
│ ├── graceful-fs@4.1.15
│ ├── has-unicode@2.0.1
│ ├── hosted-git-info@2.7.1
│ ├── iferr@1.0.2
│ ├── imurmurhash@0.1.4
│ ├─┬ inflight@1.0.6
│ │ ├── once@1.4.0
│ │ └── wrappy@1.0.2
│ ├── inherits@2.0.3
│ ├── ini@1.3.5
│ ├─┬ init-package-json@1.10.3
│ │ ├── glob@7.1.3
│ │ ├── npm-package-arg@6.1.0
│ │ ├─┬ promzard@0.3.0
│ │ │ └── read@1.0.7
│ │ ├── read@1.0.7
│ │ ├── read-package-json@2.0.13
│ │ ├── semver@5.5.1
│ │ ├── validate-npm-package-license@3.0.4
│ │ └── validate-npm-package-name@3.0.0
│ ├─┬ is-cidr@2.0.6
│ │ └─┬ cidr-regex@2.0.9
│ │   └── ip-regex@2.1.0
│ ├── json-parse-better-errors@1.0.2
│ ├─┬ JSONStream@1.3.4
│ │ ├── jsonparse@1.3.1
│ │ └── through@2.3.8
│ ├── lazy-property@1.0.0
│ ├─┬ libcipm@2.0.2
│ │ ├── bin-links@1.1.2
│ │ ├── bluebird@3.5.3
│ │ ├── find-npm-prefix@1.0.2
│ │ ├── graceful-fs@4.1.15
│ │ ├── lock-verify@2.0.2
│ │ ├── mkdirp@0.5.1
│ │ ├── npm-lifecycle@2.1.0
│ │ ├── npm-logical-tree@1.2.1
│ │ ├── npm-package-arg@6.1.0
│ │ ├── pacote@8.1.6
│ │ ├─┬ protoduck@5.0.0
│ │ │ └── genfun@4.0.1
│ │ ├── read-package-json@2.0.13
│ │ ├── rimraf@2.6.2
│ │ └── worker-farm@1.6.0
│ ├─┬ libnpmhook@4.0.1
│ │ ├── figgy-pudding@3.5.1
│ │ └─┬ npm-registry-fetch@3.1.1
│ │   ├── bluebird@3.5.3
│ │   ├── figgy-pudding@3.5.1
│ │   ├── lru-cache@4.1.3
│ │   ├── make-fetch-happen@4.0.1
│ │   └── npm-package-arg@6.1.0
│ ├─┬ libnpx@10.2.0
│ │ ├── dotenv@5.0.1
│ │ ├── npm-package-arg@6.1.0
│ │ ├── rimraf@2.6.2
│ │ ├── safe-buffer@5.1.2
│ │ ├── update-notifier@2.5.0
│ │ ├── which@1.3.1
│ │ ├── y18n@4.0.0
│ │ └─┬ yargs@11.0.0
│ │   ├─┬ cliui@4.1.0
│ │   │ ├── string-width@2.1.1
│ │   │ ├─┬ strip-ansi@4.0.0
│ │   │ │ └── ansi-regex@3.0.0
│ │   │ └─┬ wrap-ansi@2.1.0
│ │   │   ├─┬ string-width@1.0.2
│ │   │   │ ├── code-point-at@1.1.0
│ │   │   │ ├── is-fullwidth-code-point@1.0.0
│ │   │   │ └── strip-ansi@3.0.1
│ │   │   └── strip-ansi@3.0.1
│ │   ├── decamelize@1.2.0
│ │   ├─┬ find-up@2.1.0
│ │   │ └─┬ locate-path@2.0.0
│ │   │   ├─┬ p-locate@2.0.0
│ │   │   │ └─┬ p-limit@1.2.0
│ │   │   │   └── p-try@1.0.0
│ │   │   └── path-exists@3.0.0
│ │   ├── get-caller-file@1.0.2
│ │   ├─┬ os-locale@2.1.0
│ │   │ ├─┬ execa@0.7.0
│ │   │ │ ├─┬ cross-spawn@5.1.0
│ │   │ │ │ ├── lru-cache@4.1.3
│ │   │ │ │ ├─┬ shebang-command@1.2.0
│ │   │ │ │ │ └── shebang-regex@1.0.0
│ │   │ │ │ └── which@1.3.1
│ │   │ │ ├── get-stream@3.0.0
│ │   │ │ ├── is-stream@1.1.0
│ │   │ │ ├─┬ npm-run-path@2.0.2
│ │   │ │ │ └── path-key@2.0.1
│ │   │ │ ├── p-finally@1.0.0
│ │   │ │ ├── signal-exit@3.0.2
│ │   │ │ └── strip-eof@1.0.0
│ │   │ ├─┬ lcid@1.0.0
│ │   │ │ └── invert-kv@1.0.0
│ │   │ └─┬ mem@1.1.0
│ │   │   └── mimic-fn@1.2.0
│ │   ├── require-directory@2.1.1
│ │   ├── require-main-filename@1.0.1
│ │   ├── set-blocking@2.0.0
│ │   ├── string-width@2.1.1
│ │   ├── which-module@2.0.0
│ │   ├── y18n@3.2.1
│ │   └─┬ yargs-parser@9.0.2
│ │     └── camelcase@4.1.0
│ ├─┬ lock-verify@2.0.2
│ │ ├── npm-package-arg@6.1.0
│ │ └── semver@5.5.1
│ ├─┬ lockfile@1.0.4
│ │ └── signal-exit@3.0.2
│ ├── lodash._baseindexof@3.1.0
│ ├─┬ lodash._baseuniq@4.6.0
│ │ ├── lodash._createset@4.0.3
│ │ └── lodash._root@3.0.1
│ ├── lodash._bindcallback@3.0.1
│ ├── lodash._cacheindexof@3.0.2
│ ├─┬ lodash._createcache@3.1.2
│ │ └── lodash._getnative@3.9.1
│ ├── lodash._getnative@3.9.1
│ ├── lodash.clonedeep@4.5.0
│ ├── lodash.restparam@3.6.1
│ ├── lodash.union@4.6.0
│ ├── lodash.uniq@4.5.0
│ ├── lodash.without@4.4.0
│ ├─┬ lru-cache@4.1.3
│ │ ├── pseudomap@1.0.2
│ │ └── yallist@2.1.2
│ ├── meant@1.0.1
│ ├─┬ mississippi@3.0.0
│ │ ├─┬ concat-stream@1.6.2
│ │ │ ├── buffer-from@1.0.0
│ │ │ ├── inherits@2.0.3
│ │ │ ├── readable-stream@2.3.6
│ │ │ └── typedarray@0.0.6
│ │ ├─┬ duplexify@3.6.0
│ │ │ ├── end-of-stream@1.4.1
│ │ │ ├── inherits@2.0.3
│ │ │ ├── readable-stream@2.3.6
│ │ │ └── stream-shift@1.0.0
│ │ ├─┬ end-of-stream@1.4.1
│ │ │ └── once@1.4.0
│ │ ├─┬ flush-write-stream@1.0.3
│ │ │ ├── inherits@2.0.3
│ │ │ └── readable-stream@2.3.6
│ │ ├─┬ from2@2.3.0
│ │ │ ├── inherits@2.0.3
│ │ │ └── readable-stream@2.3.6
│ │ ├─┬ parallel-transform@1.1.0
│ │ │ ├── cyclist@0.2.2
│ │ │ ├── inherits@2.0.3
│ │ │ └── readable-stream@2.3.6
│ │ ├─┬ pump@3.0.0
│ │ │ ├── end-of-stream@1.4.1
│ │ │ └── once@1.4.0
│ │ ├─┬ pumpify@1.5.1
│ │ │ ├── duplexify@3.6.0
│ │ │ ├── inherits@2.0.3
│ │ │ └─┬ pump@2.0.1
│ │ │   ├── end-of-stream@1.4.1
│ │ │   └── once@1.4.0
│ │ ├─┬ stream-each@1.2.2
│ │ │ ├── end-of-stream@1.4.1
│ │ │ └── stream-shift@1.0.0
│ │ └─┬ through2@2.0.3
│ │   ├── readable-stream@2.3.6
│ │   └── xtend@4.0.1
│ ├─┬ mkdirp@0.5.1
│ │ └── minimist@0.0.8
│ ├─┬ move-concurrently@1.0.1
│ │ ├── aproba@1.2.0
│ │ ├─┬ copy-concurrently@1.0.5
│ │ │ ├── aproba@1.2.0
│ │ │ ├── fs-write-stream-atomic@1.0.10
│ │ │ ├── iferr@0.1.5
│ │ │ ├── mkdirp@0.5.1
│ │ │ ├── rimraf@2.6.2
│ │ │ └── run-queue@1.0.3
│ │ ├── fs-write-stream-atomic@1.0.10
│ │ ├── mkdirp@0.5.1
│ │ ├── rimraf@2.6.2
│ │ └─┬ run-queue@1.0.3
│ │   └── aproba@1.2.0
│ ├─┬ node-gyp@3.8.0
│ │ ├─┬ fstream@1.0.11
│ │ │ ├── graceful-fs@4.1.15
│ │ │ ├── inherits@2.0.3
│ │ │ ├── mkdirp@0.5.1
│ │ │ └── rimraf@2.6.2
│ │ ├── glob@7.1.3
│ │ ├── graceful-fs@4.1.15
│ │ ├── mkdirp@0.5.1
│ │ ├─┬ nopt@3.0.6
│ │ │ └── abbrev@1.1.1
│ │ ├── npmlog@4.1.2
│ │ ├── osenv@0.1.5
│ │ ├── request@2.88.0
│ │ ├── rimraf@2.6.2
│ │ ├── semver@5.3.0
│ │ ├─┬ tar@2.2.1
│ │ │ ├─┬ block-stream@0.0.9
│ │ │ │ └── inherits@2.0.3
│ │ │ ├── fstream@1.0.11
│ │ │ └── inherits@2.0.3
│ │ └── which@1.3.1
│ ├─┬ nopt@4.0.1
│ │ ├── abbrev@1.1.1
│ │ └── osenv@0.1.5
│ ├─┬ normalize-package-data@2.4.0
│ │ ├── hosted-git-info@2.7.1
│ │ ├─┬ is-builtin-module@1.0.0
│ │ │ └── builtin-modules@1.1.1
│ │ ├── semver@5.5.1
│ │ └── validate-npm-package-license@3.0.4
│ ├─┬ npm-audit-report@1.3.1
│ │ ├── cli-table3@0.5.0
│ │ └── console-control-strings@1.1.0
│ ├── npm-cache-filename@1.0.2
│ ├─┬ npm-install-checks@3.0.0
│ │ └── semver@5.5.1
│ ├─┬ npm-lifecycle@2.1.0
│ │ ├── byline@5.0.0
│ │ ├── graceful-fs@4.1.15
│ │ ├── node-gyp@3.8.0
│ │ ├── resolve-from@4.0.0
│ │ ├── slide@1.1.6
│ │ ├── uid-number@0.0.6
│ │ ├── umask@1.1.0
│ │ └── which@1.3.1
│ ├─┬ npm-package-arg@6.1.0
│ │ ├── hosted-git-info@2.7.1
│ │ ├── osenv@0.1.5
│ │ ├── semver@5.5.1
│ │ └── validate-npm-package-name@3.0.0
│ ├─┬ npm-packlist@1.1.12
│ │ ├─┬ ignore-walk@3.0.1
│ │ │ └── minimatch@3.0.4
│ │ └── npm-bundled@1.0.5
│ ├─┬ npm-pick-manifest@2.1.0
│ │ ├── npm-package-arg@6.1.0
│ │ └── semver@5.5.1
│ ├─┬ npm-profile@3.0.2
│ │ ├── aproba@1.2.0
│ │ └─┬ make-fetch-happen@4.0.1
│ │   ├─┬ agentkeepalive@3.4.1
│ │   │ └─┬ humanize-ms@1.2.1
│ │   │   └── ms@2.1.1
│ │   ├── cacache@11.2.0
│ │   ├── http-cache-semantics@3.8.1
│ │   ├─┬ http-proxy-agent@2.1.0
│ │   │ ├─┬ agent-base@4.2.0
│ │   │ │ └─┬ es6-promisify@5.0.0
│ │   │ │   └── es6-promise@4.2.4
│ │   │ └─┬ debug@3.1.0
│ │   │   └── ms@2.0.0
│ │   ├─┬ https-proxy-agent@2.2.1
│ │   │ ├── agent-base@4.2.0
│ │   │ └── debug@3.1.0
│ │   ├── lru-cache@4.1.3
│ │   ├── mississippi@3.0.0
│ │   ├─┬ node-fetch-npm@2.0.2
│ │   │ ├─┬ encoding@0.1.12
│ │   │ │ └─┬ iconv-lite@0.4.23
│ │   │ │   └── safer-buffer@2.1.2
│ │   │ ├── json-parse-better-errors@1.0.2
│ │   │ └── safe-buffer@5.1.2
│ │   ├── promise-retry@1.1.1
│ │   ├─┬ socks-proxy-agent@4.0.1
│ │   │ ├── agent-base@4.2.0
│ │   │ └─┬ socks@2.2.0
│ │   │   ├── ip@1.1.5
│ │   │   └── smart-buffer@4.0.1
│ │   └── ssri@6.0.1
│ ├─┬ npm-registry-client@8.6.0
│ │ ├── concat-stream@1.6.2
│ │ ├── graceful-fs@4.1.15
│ │ ├── normalize-package-data@2.4.0
│ │ ├── npm-package-arg@6.1.0
│ │ ├── npmlog@4.1.2
│ │ ├── once@1.4.0
│ │ ├── request@2.88.0
│ │ ├── retry@0.10.1
│ │ ├── safe-buffer@5.1.2
│ │ ├── semver@5.5.1
│ │ ├── slide@1.1.6
│ │ └─┬ ssri@5.3.0
│ │   └── safe-buffer@5.1.2
│ ├─┬ npm-registry-fetch@1.1.0
│ │ ├── bluebird@3.5.3
│ │ ├── figgy-pudding@2.0.1
│ │ ├── lru-cache@4.1.3
│ │ ├─┬ make-fetch-happen@3.0.0
│ │ │ ├── agentkeepalive@3.4.1
│ │ │ ├─┬ cacache@10.0.4
│ │ │ │ ├── bluebird@3.5.3
│ │ │ │ ├── chownr@1.0.1
│ │ │ │ ├── glob@7.1.3
│ │ │ │ ├── graceful-fs@4.1.15
│ │ │ │ ├── lru-cache@4.1.3
│ │ │ │ ├─┬ mississippi@2.0.0
│ │ │ │ │ ├── concat-stream@1.6.2
│ │ │ │ │ ├── duplexify@3.6.0
│ │ │ │ │ ├── end-of-stream@1.4.1
│ │ │ │ │ ├── flush-write-stream@1.0.3
│ │ │ │ │ ├── from2@2.3.0
│ │ │ │ │ ├── parallel-transform@1.1.0
│ │ │ │ │ ├─┬ pump@2.0.1
│ │ │ │ │ │ ├── end-of-stream@1.4.1
│ │ │ │ │ │ └── once@1.4.0
│ │ │ │ │ ├── pumpify@1.5.1
│ │ │ │ │ ├── stream-each@1.2.2
│ │ │ │ │ └── through2@2.0.3
│ │ │ │ ├── mkdirp@0.5.1
│ │ │ │ ├── move-concurrently@1.0.1
│ │ │ │ ├── promise-inflight@1.0.1
│ │ │ │ ├── rimraf@2.6.2
│ │ │ │ ├── ssri@5.3.0
│ │ │ │ ├── unique-filename@1.1.0
│ │ │ │ └── y18n@4.0.0
│ │ │ ├── http-cache-semantics@3.8.1
│ │ │ ├── http-proxy-agent@2.1.0
│ │ │ ├── https-proxy-agent@2.2.1
│ │ │ ├── lru-cache@4.1.3
│ │ │ ├── mississippi@3.0.0
│ │ │ ├── node-fetch-npm@2.0.2
│ │ │ ├── promise-retry@1.1.1
│ │ │ ├─┬ socks-proxy-agent@3.0.1
│ │ │ │ ├── agent-base@4.2.0
│ │ │ │ └─┬ socks@1.1.10
│ │ │ │   ├── ip@1.1.5
│ │ │ │   └── smart-buffer@1.1.15
│ │ │ └─┬ ssri@5.3.0
│ │ │   └── safe-buffer@5.1.2
│ │ ├── npm-package-arg@6.1.0
│ │ └── safe-buffer@5.1.2
│ ├── npm-user-validate@1.0.0
│ ├─┬ npmlog@4.1.2
│ │ ├─┬ are-we-there-yet@1.1.4
│ │ │ ├── delegates@1.0.0
│ │ │ └── readable-stream@2.3.6
│ │ ├── console-control-strings@1.1.0
│ │ ├─┬ gauge@2.7.4
│ │ │ ├── aproba@1.2.0
│ │ │ ├── console-control-strings@1.1.0
│ │ │ ├── has-unicode@2.0.1
│ │ │ ├── object-assign@4.1.1
│ │ │ ├── signal-exit@3.0.2
│ │ │ ├─┬ string-width@1.0.2
│ │ │ │ ├── code-point-at@1.1.0
│ │ │ │ ├─┬ is-fullwidth-code-point@1.0.0
│ │ │ │ │ └── number-is-nan@1.0.1
│ │ │ │ └── strip-ansi@3.0.1
│ │ │ ├── strip-ansi@3.0.1
│ │ │ └─┬ wide-align@1.1.2
│ │ │   └─┬ string-width@1.0.2
│ │ │     ├── code-point-at@1.1.0
│ │ │     ├── is-fullwidth-code-point@1.0.0
│ │ │     └── strip-ansi@3.0.1
│ │ └── set-blocking@2.0.0
│ ├─┬ once@1.4.0
│ │ └── wrappy@1.0.2
│ ├── opener@1.5.1
│ ├─┬ osenv@0.1.5
│ │ ├── os-homedir@1.0.2
│ │ └── os-tmpdir@1.0.2
│ ├─┬ pacote@8.1.6
│ │ ├── bluebird@3.5.3
│ │ ├── cacache@11.2.0
│ │ ├── get-stream@3.0.0
│ │ ├── glob@7.1.3
│ │ ├── lru-cache@4.1.3
│ │ ├── make-fetch-happen@4.0.1
│ │ ├── minimatch@3.0.4
│ │ ├─┬ minipass@2.3.3
│ │ │ ├── safe-buffer@5.1.2
│ │ │ └── yallist@3.0.2
│ │ ├── mississippi@3.0.0
│ │ ├── mkdirp@0.5.1
│ │ ├── normalize-package-data@2.4.0
│ │ ├── npm-package-arg@6.1.0
│ │ ├── npm-packlist@1.1.12
│ │ ├── npm-pick-manifest@2.1.0
│ │ ├── osenv@0.1.5
│ │ ├── promise-inflight@1.0.1
│ │ ├─┬ promise-retry@1.1.1
│ │ │ ├── err-code@1.1.2
│ │ │ └── retry@0.10.1
│ │ ├── protoduck@5.0.0
│ │ ├── rimraf@2.6.2
│ │ ├── safe-buffer@5.1.2
│ │ ├── semver@5.5.1
│ │ ├── ssri@6.0.1
│ │ ├── tar@4.4.8
│ │ ├── unique-filename@1.1.0
│ │ └── which@1.3.1
│ ├── path-is-inside@1.0.2
│ ├── promise-inflight@1.0.1
│ ├── qrcode-terminal@0.12.0
│ ├─┬ query-string@6.1.0
│ │ ├── decode-uri-component@0.2.0
│ │ └── strict-uri-encode@2.0.0
│ ├── qw@1.0.1
│ ├─┬ read@1.0.7
│ │ └── mute-stream@0.0.7
│ ├─┬ read-cmd-shim@1.0.1
│ │ └── graceful-fs@4.1.15
│ ├─┬ read-installed@4.0.3
│ │ ├── debuglog@1.0.1
│ │ ├── graceful-fs@4.1.15
│ │ ├── read-package-json@2.0.13
│ │ ├── readdir-scoped-modules@1.0.2
│ │ ├── semver@5.5.1
│ │ ├── slide@1.1.6
│ │ └── util-extend@1.0.3
│ ├─┬ read-package-json@2.0.13
│ │ ├── glob@7.1.3
│ │ ├── graceful-fs@4.1.15
│ │ ├── json-parse-better-errors@1.0.2
│ │ ├── normalize-package-data@2.4.0
│ │ └── slash@1.0.0
│ ├─┬ read-package-tree@5.2.1
│ │ ├── debuglog@1.0.1
│ │ ├── dezalgo@1.0.3
│ │ ├── once@1.4.0
│ │ ├── read-package-json@2.0.13
│ │ └── readdir-scoped-modules@1.0.2
│ ├─┬ readable-stream@2.3.6
│ │ ├── core-util-is@1.0.2
│ │ ├── inherits@2.0.3
│ │ ├── isarray@1.0.0
│ │ ├── process-nextick-args@2.0.0
│ │ ├── safe-buffer@5.1.2
│ │ ├─┬ string_decoder@1.1.1
│ │ │ └── safe-buffer@5.1.2
│ │ └── util-deprecate@1.0.2
│ ├─┬ readdir-scoped-modules@1.0.2
│ │ ├── debuglog@1.0.1
│ │ ├── dezalgo@1.0.3
│ │ ├── graceful-fs@4.1.15
│ │ └── once@1.4.0
│ ├─┬ request@2.88.0
│ │ ├── aws-sign2@0.7.0
│ │ ├── aws4@1.8.0
│ │ ├── caseless@0.12.0
│ │ ├─┬ combined-stream@1.0.6
│ │ │ └── delayed-stream@1.0.0
│ │ ├── extend@3.0.2
│ │ ├── forever-agent@0.6.1
│ │ ├─┬ form-data@2.3.2
│ │ │ ├── asynckit@0.4.0
│ │ │ ├── combined-stream@1.0.6
│ │ │ └── mime-types@2.1.19
│ │ ├─┬ har-validator@5.1.0
│ │ │ ├─┬ ajv@5.5.2
│ │ │ │ ├── co@4.6.0
│ │ │ │ ├── fast-deep-equal@1.1.0
│ │ │ │ ├── fast-json-stable-stringify@2.0.0
│ │ │ │ └── json-schema-traverse@0.3.1
│ │ │ └── har-schema@2.0.0
│ │ ├─┬ http-signature@1.2.0
│ │ │ ├── assert-plus@1.0.0
│ │ │ ├─┬ jsprim@1.4.1
│ │ │ │ ├── assert-plus@1.0.0
│ │ │ │ ├── extsprintf@1.3.0
│ │ │ │ ├── json-schema@0.2.3
│ │ │ │ └─┬ verror@1.10.0
│ │ │ │   ├── assert-plus@1.0.0
│ │ │ │   ├── core-util-is@1.0.2
│ │ │ │   └── extsprintf@1.3.0
│ │ │ └─┬ sshpk@1.14.2
│ │ │   ├─┬ asn1@0.2.4
│ │ │   │ └── safer-buffer@2.1.2
│ │ │   ├── assert-plus@1.0.0
│ │ │   ├─┬ bcrypt-pbkdf@1.0.2
│ │ │   │ └── tweetnacl@0.14.5
│ │ │   ├─┬ dashdash@1.14.1
│ │ │   │ └── assert-plus@1.0.0
│ │ │   ├─┬ ecc-jsbn@0.1.2
│ │ │   │ ├── jsbn@0.1.1
│ │ │   │ └── safer-buffer@2.1.2
│ │ │   ├─┬ getpass@0.1.7
│ │ │   │ └── assert-plus@1.0.0
│ │ │   ├── jsbn@0.1.1
│ │ │   ├── safer-buffer@2.1.2
│ │ │   └── tweetnacl@0.14.5
│ │ ├── is-typedarray@1.0.0
│ │ ├── isstream@0.1.2
│ │ ├── json-stringify-safe@5.0.1
│ │ ├─┬ mime-types@2.1.19
│ │ │ └── mime-db@1.35.0
│ │ ├── oauth-sign@0.9.0
│ │ ├── performance-now@2.1.0
│ │ ├── qs@6.5.2
│ │ ├── safe-buffer@5.1.2
│ │ ├─┬ tough-cookie@2.4.3
│ │ │ ├── psl@1.1.29
│ │ │ └── punycode@1.4.1
│ │ ├─┬ tunnel-agent@0.6.0
│ │ │ └── safe-buffer@5.1.2
│ │ └── uuid@3.3.2
│ ├── retry@0.12.0
│ ├─┬ rimraf@2.6.2
│ │ └── glob@7.1.3
│ ├── safe-buffer@5.1.2
│ ├── semver@5.5.1
│ ├─┬ sha@2.0.1
│ │ ├── graceful-fs@4.1.15
│ │ └── readable-stream@2.3.6
│ ├── slide@1.1.6
│ ├── sorted-object@2.0.1
│ ├─┬ sorted-union-stream@2.1.3
│ │ ├─┬ from2@1.3.0
│ │ │ ├── inherits@2.0.3
│ │ │ └─┬ readable-stream@1.1.14
│ │ │   ├── core-util-is@1.0.2
│ │ │   ├── inherits@2.0.3
│ │ │   ├── isarray@0.0.1
│ │ │   └── string_decoder@0.10.31
│ │ └─┬ stream-iterate@1.2.0
│ │   ├── readable-stream@2.3.6
│ │   └── stream-shift@1.0.0
│ ├─┬ ssri@6.0.1
│ │ └── figgy-pudding@3.5.1
│ ├── stringify-package@1.0.0
│ ├─┬ tar@4.4.8
│ │ ├── chownr@1.1.1
│ │ ├─┬ fs-minipass@1.2.5
│ │ │ └── minipass@2.3.3
│ │ ├─┬ minipass@2.3.5
│ │ │ ├── safe-buffer@5.1.2
│ │ │ └── yallist@3.0.3
│ │ ├─┬ minizlib@1.1.1
│ │ │ └── minipass@2.3.3
│ │ ├── mkdirp@0.5.1
│ │ ├── safe-buffer@5.1.2
│ │ └── yallist@3.0.3
│ ├── text-table@0.2.0
│ ├── tiny-relative-date@1.3.0
│ ├── uid-number@0.0.6
│ ├── umask@1.1.0
│ ├─┬ unique-filename@1.1.0
│ │ └─┬ unique-slug@2.0.0
│ │   └── imurmurhash@0.1.4
│ ├── unpipe@1.0.0
│ ├─┬ update-notifier@2.5.0
│ │ ├─┬ boxen@1.3.0
│ │ │ ├─┬ ansi-align@2.0.0
│ │ │ │ └── string-width@2.1.1
│ │ │ ├── camelcase@4.1.0
│ │ │ ├── chalk@2.4.1
│ │ │ ├── cli-boxes@1.0.0
│ │ │ ├── string-width@2.1.1
│ │ │ ├─┬ term-size@1.2.0
│ │ │ │ └── execa@0.7.0
│ │ │ └─┬ widest-line@2.0.0
│ │ │   └── string-width@2.1.1
│ │ ├─┬ chalk@2.4.1
│ │ │ ├─┬ ansi-styles@3.2.1
│ │ │ │ └─┬ color-convert@1.9.1
│ │ │ │   └── color-name@1.1.3
│ │ │ ├── escape-string-regexp@1.0.5
│ │ │ └─┬ supports-color@5.4.0
│ │ │   └── has-flag@3.0.0
│ │ ├─┬ configstore@3.1.2
│ │ │ ├─┬ dot-prop@4.2.0
│ │ │ │ └── is-obj@1.0.1
│ │ │ ├── graceful-fs@4.1.15
│ │ │ ├─┬ make-dir@1.3.0
│ │ │ │ └── pify@3.0.0
│ │ │ ├─┬ unique-string@1.0.0
│ │ │ │ └── crypto-random-string@1.0.0
│ │ │ ├── write-file-atomic@2.3.0
│ │ │ └── xdg-basedir@3.0.0
│ │ ├── import-lazy@2.1.0
│ │ ├─┬ is-ci@1.1.0
│ │ │ └── ci-info@1.6.0
│ │ ├─┬ is-installed-globally@0.1.0
│ │ │ ├─┬ global-dirs@0.1.1
│ │ │ │ └── ini@1.3.5
│ │ │ └─┬ is-path-inside@1.0.1
│ │ │   └── path-is-inside@1.0.2
│ │ ├── is-npm@1.0.0
│ │ ├─┬ latest-version@3.1.0
│ │ │ └─┬ package-json@4.0.1
│ │ │   ├─┬ got@6.7.1
│ │ │   │ ├─┬ create-error-class@3.0.2
│ │ │   │ │ └── capture-stack-trace@1.0.0
│ │ │   │ ├── duplexer3@0.1.4
│ │ │   │ ├── get-stream@3.0.0
│ │ │   │ ├── is-redirect@1.0.0
│ │ │   │ ├── is-retry-allowed@1.1.0
│ │ │   │ ├── is-stream@1.1.0
│ │ │   │ ├── lowercase-keys@1.0.1
│ │ │   │ ├── safe-buffer@5.1.2
│ │ │   │ ├── timed-out@4.0.1
│ │ │   │ ├── unzip-response@2.0.1
│ │ │   │ └─┬ url-parse-lax@1.0.0
│ │ │   │   └── prepend-http@1.0.4
│ │ │   ├─┬ registry-auth-token@3.3.2
│ │ │   │ ├─┬ rc@1.2.7
│ │ │   │ │ ├── deep-extend@0.5.1
│ │ │   │ │ ├── ini@1.3.5
│ │ │   │ │ ├── minimist@1.2.0
│ │ │   │ │ └── strip-json-comments@2.0.1
│ │ │   │ └── safe-buffer@5.1.2
│ │ │   ├─┬ registry-url@3.1.0
│ │ │   │ └── rc@1.2.7
│ │ │   └── semver@5.5.1
│ │ ├─┬ semver-diff@2.1.0
│ │ │ └── semver@5.5.1
│ │ └── xdg-basedir@3.0.0
│ ├── uuid@3.3.2
│ ├─┬ validate-npm-package-license@3.0.4
│ │ ├─┬ spdx-correct@3.0.0
│ │ │ ├── spdx-expression-parse@3.0.0
│ │ │ └── spdx-license-ids@3.0.0
│ │ └─┬ spdx-expression-parse@3.0.0
│ │   ├── spdx-exceptions@2.1.0
│ │   └── spdx-license-ids@3.0.0
│ ├─┬ validate-npm-package-name@3.0.0
│ │ └── builtins@1.0.3
│ ├─┬ which@1.3.1
│ │ └── isexe@2.0.0
│ ├─┬ worker-farm@1.6.0
│ │ └─┬ errno@0.1.7
│ │   └── prr@1.0.1
│ └─┬ write-file-atomic@2.3.0
│   ├── graceful-fs@4.1.15
│   ├── imurmurhash@0.1.4
│   └── signal-exit@3.0.2
├─┬ rc@1.2.8
│ ├── deep-extend@0.6.0
│ ├── ini@1.3.5
│ ├── minimist@1.2.0
│ └── strip-json-comments@2.0.1
├─┬ read-pkg@4.0.1
│ ├── normalize-package-data@2.5.0
│ ├── parse-json@4.0.0
│ └── pify@3.0.0
├─┬ registry-auth-token@3.4.0
│ ├── rc@1.2.8
│ └── safe-buffer@5.2.0
└── semver@5.7.0

New feature description

It will be great if @semantic-release/npm can be an optional dependency. For backwards compatibility, it should be possible to create a bare-bone version of semantic-release without all the bloat and let users add plugins they need.

A similar request was proposed in #827 but it doesn't seem to be solved.

The text was updated successfully, but these errors were encountered:

DanielHabenicht · 2019-09-04T08:28:37Z

I think that it would be a huge benefit too.

I would propose to refactor the standard installation into a sharable configuration and leave it to the user to install what he needs. (We could alter getting started documentation to install the npm-config together with semantic-release in order to not make it harder for the standard use case -> npm install semantic-release @semantic-release/npm-config).

I would even go as far as removing almost anything that is not really needed for a plain semantic-release installation, e.g. @semantic-release/github (maybe even release-notes-generator).
By the way, what is the core functionality of semantic-release without any plugin, is there any?

This would further allow a new user to understand how semantic release works, as of now it just magically works out of the box without configuring anything. (That's something my coworkers complained about!)
Stating that it uses the shareable config in the configuration file provides the necessary information to the user on what is configured and what he has to change in order to alter his release process.

gr2m · 2019-09-04T18:55:17Z

I could imagine to have semantic-release as-is, but offer a @semantic-release/core package without any plugins loaded for more advanced users.

DanielHabenicht · 2019-09-04T19:56:26Z

But what would be the difference between semantic-release and @semantic-release/core? The difference would only lay in the installed packages and the standard config. In my opinion that's a little bit contradicting as this is already configurable.

I appreciate your effort to not make a breaking change but this will be at the cost of clarity of this project.
Like I already said: It is great that semantic-release just works out of the box, but that raises the bar for changing the magic config that is invisible to the user. Providing a preset that everybody can see at the cost of one more package to install is reasonable in my opinion (further backed by a much smaller footprint of the main package).

pvdlg · 2019-09-13T21:52:03Z

By the way, what is the core functionality of semantic-release without any plugin, is there any?

Determine the next version, create and push a Git tag.

This would further allow a new user to understand how semantic release works, as of now it just magically works out of the box without configuring anything. (That's something my coworkers complained about!)

Well, half of people complains if it works without config, the other half complains if it requires config. 🤷‍♂️

Originally semantic-release didn't had plugins and npm and github publish were hardcoded. A large part of the user base started to use it then. They most likely do not have any plugins installed in their pacakge.json not any config. Each one of them would have to install 4 plugins and add the necessary config. That's quite a lot.

DanielHabenicht · 2019-09-13T23:36:44Z

Determine the next version, create and push a Git tag.

Thanks for clearing up. 👍

Well, half of people complains if it works without config, the other half complains if it requires config. 🤷‍♂️

In my mind, the declarative way is more attractive. Everybody can clearly see what's going on, nobody has to search for the default behaviour.
Further, as you said, semantic-release core functionality is not releasing npm packages (although it was) but determining "the next version, create and push a Git tag". Everything else should be visible for the user, as it extends the standard functionality.

Originally semantic-release didn't had plugins and npm and github publish were hardcoded. A large part of the user base started to use it then. They most likely do not have any plugins installed in their pacakge.json not any config. Each one of them would have to install 4 plugins and add the necessary config. That's quite a lot.

Semantic-Release does have a cli to ease the pain of installing, executing semantic-release-cli setup could incorporate all the steps mentioned by you (so there would be no extra work for new projects).

For existing projects we should make a pro-contra table:

Pro 👍	Contra 👎
---	update pain (once)
more disk space (every time)	must add more packages (once)
faster `npm install` (every time)	---
A config file!	A config file?
make this plugin core open to technologies without favouring one	update pain for maintainers (resolving issues and answering questions)
fewer security issues through dependencies

Feel free to add more comments, I will update the table.

"They most likely do not have any plugins installed in their pacakge.json not any config. "

The update pain could be soothed by adding a semantic-release-cli update command which makes updates in between major version less painful (also for the future), thus automatically adding the default config and installing the shared-config. This could be made a requirement for this issue.

"Each one of them would have to install 4 plugins"

Semantic-Release already supports shareable-configs. The current default could be exported into one, thus minimizing the complexity for existing projects by only having to install one package and adding 4 lines of config.

I would be interested in some numbers - how many are using semantic-release in the default config, how many are using a custom one. But they will be hard to get. Maybe someone can analyze the dependent repositories for .releaserc and release properties in the package.json.

Furthermore: I think semantic-release is a cool, rock-solid, easy expandable tool that can be used in so much more cases than just releasing an npm package. Restricting it to just npm makes no sense.

pvdlg · 2019-09-19T20:10:11Z

In my mind, the declarative way is more attractive. Everybody can clearly see what's going on, nobody has to search for the default behaviour.
Further, as you said, semantic-release core functionality is not releasing npm packages (although it was) but determining "the next version, create and push a Git tag". Everything else should be visible for the user, as it extends the standard functionality.

I understand the argument and I'm not disagreeing. I'm just saying that as soon as we make such change we'll get 25 identical issues open on this repo saying a version of "I updated without reading the changelog, my npm package is not published anymore, please fix it".

Overall I would be in favor of having no plugin by default and allow users to add whatever they need. The changes in the code might be simple to do, however the amount of work in terms of communication, support and issue management is enormous.
I don't think at that point it's a worthwhile trade-off and I personally don't have time to manage that.

leethree · 2019-09-19T21:19:29Z

@pvdlg what do you think of the proposal of adding a @semantic-release/core package without any plugins?

pvdlg · 2019-09-23T16:50:45Z

That would create a lot of additional maintenance as we would have to either:

Make a copy of the semantic-release repo, remove the plugins dependency there and keep it updated
Maintain some sort of script that would release semantic-release, then remove plugin dependencies then release semantic-release/core. That script would have to modify the code where we set the default plugins as well

Both solution seems clunky and hard to maintain.

dominykas · 2019-09-23T19:01:17Z

Would it not make sense instead to release semantic-release/core from this repo instead? And have a new repo, with plugins, to release the "full" version?

gr2m · 2019-09-23T19:07:33Z

We will revisit this discussion after we ship out the current beta. Feel free to keep commenting, just wanted to explain that we probably won't engage with it as much for the time being

DanielHabenicht · 2019-09-24T12:36:09Z

Would it not make sense instead to release semantic-release/core from this repo instead? And have a new repo, with plugins, to release the "full" version?

Naming wise semantic-release is the core already. The full versions are covered by the shared configs as far as I am concerned.
As a user, I would be confused about why some projects are using only semantic-release while others are using semantic-release/core and semantic-release/npm-config, which are both accomplishing the same.

I would be happy to contribute an update tool to the CLI for Christmas, or maybe this can also be done by a npm postinstall step?

DanielHabenicht · 2019-09-24T12:39:09Z

@leethree @dominykas Ohh, wait I think I misunderstood. By releasing @semantic-release/core you mean effectively deprecating semantic-release and urging the users to use the new package with configs?
This could be done over a longer period of time and without breaking peoples builds.
But would come with more overhead for maintainers of the packages using semantic-release.

dominykas · 2019-09-24T16:42:21Z

you mean effectively deprecating semantic-release and urging the users to use the new package with configs

No, why would you do that? semantic-release could bundle @semantic-release/core + plugins + default config with npm, people would still be free to use it, while the advanced users, looking to squeeze out that extra bit of perf during CI could skip all of that and rely on just the core + custom config.

There are many good and non-complicated options to manage the two separate packages from the perspective of semantic-release maintainers.

travi · 2019-09-24T16:54:27Z

you mean effectively deprecating semantic-release and urging the users to use the new package with configs

No, why would you do that?

this would be my assumption too. if the core was extracted, i would think it would make the most sense to deprecate the current package in favor of a shareable-config instead. that would still provide the bundling that exists today, but in a more explicit way.

travi · 2019-09-24T16:59:40Z

one thing that comes to mind if a transition like this is pursued would be the behavior of running semantic-release with npx. i'm not sure i fully have my head around how npx finds the proper package when it is not installed locally, but i would think that either @semantic-release/core or a @semantic-release/cli package would be the desired target, but not sure what the best way to transition that piece would be.

dominykas · 2019-09-24T17:34:27Z

If @semantic-release/core is a dependency of semantic-release and contains a semantic-release bin, then having either one installed would work with npx semantic-release. Otherwise it would download semantic-release. Or you can pass it a -p @semantic-release/core.

The @semantic-release/cli, I believe, has a different purpose right now.

travi · 2019-09-24T18:17:27Z

the current cli for configuring projects is semantic-release-cli, but also having a @semantic-release/cli could certainly introduce confusion.

Otherwise it would download semantic-release. Or you can pass it a -p @semantic-release/core.

this does make sense. i could swear i've seen in handle cases where the command didnt match the package name without the flag, but like i said, i haven't paid close enough attention.

McRegt · 2019-10-03T05:15:05Z

We're using the semantic-release package in our Azure DevOps pipelines, which due to the dependencies takes ages to load:

added 742 packages from 1000 contributors in 138.844s

The only thing we do with semantic-release is calculate the version number and set it on a pipeline variable using the semantic-release-ado plugin.

As far as solutions go, considering all that has been said so far is to introduce an option to the configuration, that allows for the skipping of all default plugins.

{
	"release": {
		"useDefaultPlugins": false
	}
}

Normally I'm against introducing booleans to manage (breaking) changes. But considering what's been said it provides the possibility to have the best of both worlds:

Existing installations and configuration would remain working (given you act on the default value being true).
If desired, the option can be used to reduce the package load, but it's an conscious decision to do so.
It would have no or limited impact in terms of effort required for communication and issue management.

DanielHabenicht · 2019-10-03T20:20:56Z

That would be a nice option. It`s time-efficient, can be implemented right away and is non-breaking. Also, it leaves open the future implementation.

pvdlg · 2019-10-03T20:44:11Z

The default plugins are defined as a dependency of semantic-release in the package.json. As such they will always be installed when running npm install.
Adding the option you are suggesting wouldn't change that.

McRegt · 2019-10-07T06:35:46Z

How about indicating them as optionalDependencies? npm link.

This would install the packages by default and allow for them to be 'excluded' by running the npm-install command with the --no-optional toggle.

DanielHabenicht · 2019-11-28T19:01:08Z

I am happy to support you now. What has to be done to get this implemented?

I would create a shared config @semantic-release/default-config with the current default configuration to further separate it from the main part of semantic-release.
Also, I can make a PR for making the dependencies optional.

DanielHabenicht · 2019-12-18T09:46:14Z

@pvdlg any updates on this?

To implement this issue I would:

Create a shared config @semantic-release/npm-config with the current default config (you can copy the repo than)
Make a PR for making the shared-config optional.

pvdlg · 2019-12-18T18:20:54Z

See #1260 (comment). We won't address that at the moment.

It's not blocking nor preventing anything to work, it's just a micro optimization that would avoid copying a few files from the npm cache to the local node_modules on npm install. I'm not even sure the time you'd save on npm install would even be measurable...it would probably be a few dozen of ms at best and only in the rare case of the cache being empty....

We'll re-evaluate how we want to handle plugins and shareable config after v16 is released.

DanielHabenicht · 2019-12-20T12:09:44Z

Well for the main use case of semantic-release the package is installed on a vanilla server during the CI-CD-Chain. This machine always has an empty cache.

For comparison that's the size of the packages (installed):

What brought me here, in the beginning, is that Azure Pipelines tasks are capped at a maximum package size (20MB). Distributing semantic-release in that package is therefore not possible and it has to be installed in the pipeline (via npm, which is taking its time) instead of just unzipping it.

pvdlg · 2019-12-21T01:00:14Z

I see. If you remove the @semantic-release/npm and @semantic-release/github from the package.json, would that even fit in this 20MB limitation?

I don't know anything about Azure Pipelines tasks, but out of curiosity wouldn't it be better to install semantic-release on execution rather than embedding it?
This way:

You would get the last semantic-release version without having to update your pipeline
Users could specify the version of semantic-release they want to use via devDependencies as npx would pick that version from the package.json

avaragado · 2021-05-14T09:35:01Z

I've hit this issue in my project, which doesn't deploy built packages to any npm registry and so doesn't need @semantic-release/npm.

It's a problem for me because @semantic-release/npm has a dependency on npm, which results in a mismatch between the npm in node_modules (currently 7.11.2) and the npm in my shell environment (currently 6.4.10). For tedious build infrastructure reasons I can't upgrade npm for my shell at present.

The effect: npm operations invoked indirectly (eg by scripts called from package.json scripts) pick up v7.11.2 unless you mess with PATH.

weyert · 2021-07-01T12:17:12Z

Yes, I am experiencing the same issue were using npm in scripts definitions in my package.json always use npm v7 which is problematic when I am using npm install in a script definition.

joostvdwsd · 2021-07-13T14:04:41Z

We've been using semantic-release for a while now and also put it in build tools for other departments in our company. Our main issue is actually this addressed issue. We use nothing of the @semantic-release/npm package and it adds a massive dependency tree. This results in a lot of questions from the other departments why we add such a heavy dependency tree and why we need it.

Both the @semantic-release/core idea as optionalDependencies sound good. A tool which is so flexible with plugins should have a very small core I think.

If the maintenance between the core package and "full" package is an issue when developing you could think of changing the repo in a mono repo with both packages (also include maybe the other main plugin packages).

joostvdwsd · 2021-08-10T11:54:07Z

The @semantic-release/npm dependency is giving us major issues on multiple levels. Getting around this dependency feels more hacky by the day and actually already costs a lot of time researching unexpected behaviors.

dependency tree is extremely large due to the npm dependency (which is unneeded due to locally installed npm)
we can't use the @semantic-release/npm plugin due to this bug with no-auth private repositories Allow running without an configured NPM_TOKEN npm#324
@semantic-release/npm enforces npm 7 while we need 6 (also due to a bug in npm 7 related to private repositories)

We love semantic release for all our package. However, this disabled plugin that gets shipped with breaks all natural logic to work with it

the-spyke · 2021-12-23T18:43:11Z

There're pull requests for this: semantic-release/npm#444 and semantic-release/npm#445

Please also remove GitHub from the dependencies.

rodrigorodriguez · 2022-11-21T16:49:26Z

warning semantic-release > @semantic-release/npm > npm > readdir-scoped-modules@1.1.0: This functionality has been moved to @npmcli/fs.

"semantic-release": "19.0.5"

travi mentioned this issue Oct 8, 2019

Re-use global plugins inside shareable configurations #1309

Open

pvdlg mentioned this issue Nov 25, 2019

Roadmap #1134

Closed

pvdlg mentioned this issue Feb 6, 2020

Automatically install plugins not built in #1445

Closed

travi mentioned this issue Feb 25, 2020

Use example markdown generated from code instead of hand-written form8ion/project#263

Merged

travi mentioned this issue Oct 20, 2020

Switch default preset from angular to conventionalcommits #1652

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Do not include @semantic-release/npm by default #1260

Do not include @semantic-release/npm by default #1260

leethree commented Aug 13, 2019 •

edited by gr2m

DanielHabenicht commented Sep 4, 2019

gr2m commented Sep 4, 2019

DanielHabenicht commented Sep 4, 2019

pvdlg commented Sep 13, 2019

DanielHabenicht commented Sep 13, 2019 •

edited

pvdlg commented Sep 19, 2019

leethree commented Sep 19, 2019

pvdlg commented Sep 23, 2019

dominykas commented Sep 23, 2019

gr2m commented Sep 23, 2019

DanielHabenicht commented Sep 24, 2019

DanielHabenicht commented Sep 24, 2019 •

edited

dominykas commented Sep 24, 2019 •

edited

travi commented Sep 24, 2019

travi commented Sep 24, 2019

dominykas commented Sep 24, 2019 •

edited

travi commented Sep 24, 2019

McRegt commented Oct 3, 2019 •

edited

DanielHabenicht commented Oct 3, 2019

pvdlg commented Oct 3, 2019

McRegt commented Oct 7, 2019

DanielHabenicht commented Nov 28, 2019

DanielHabenicht commented Dec 18, 2019

pvdlg commented Dec 18, 2019

DanielHabenicht commented Dec 20, 2019

pvdlg commented Dec 21, 2019 •

edited

avaragado commented May 14, 2021

weyert commented Jul 1, 2021

joostvdwsd commented Jul 13, 2021

joostvdwsd commented Aug 10, 2021

the-spyke commented Dec 23, 2021

rodrigorodriguez commented Nov 21, 2022

Do not include @semantic-release/npm by default #1260

Do not include @semantic-release/npm by default #1260

Comments

leethree commented Aug 13, 2019 • edited by gr2m

New feature motivation

New feature description

DanielHabenicht commented Sep 4, 2019

gr2m commented Sep 4, 2019

DanielHabenicht commented Sep 4, 2019

pvdlg commented Sep 13, 2019

DanielHabenicht commented Sep 13, 2019 • edited

pvdlg commented Sep 19, 2019

leethree commented Sep 19, 2019

pvdlg commented Sep 23, 2019

dominykas commented Sep 23, 2019

gr2m commented Sep 23, 2019

DanielHabenicht commented Sep 24, 2019

DanielHabenicht commented Sep 24, 2019 • edited

dominykas commented Sep 24, 2019 • edited

travi commented Sep 24, 2019

travi commented Sep 24, 2019

dominykas commented Sep 24, 2019 • edited

travi commented Sep 24, 2019

McRegt commented Oct 3, 2019 • edited

DanielHabenicht commented Oct 3, 2019

pvdlg commented Oct 3, 2019

McRegt commented Oct 7, 2019

DanielHabenicht commented Nov 28, 2019

DanielHabenicht commented Dec 18, 2019

pvdlg commented Dec 18, 2019

DanielHabenicht commented Dec 20, 2019

pvdlg commented Dec 21, 2019 • edited

avaragado commented May 14, 2021

weyert commented Jul 1, 2021

joostvdwsd commented Jul 13, 2021

joostvdwsd commented Aug 10, 2021

the-spyke commented Dec 23, 2021

rodrigorodriguez commented Nov 21, 2022

leethree commented Aug 13, 2019 •

edited by gr2m

DanielHabenicht commented Sep 13, 2019 •

edited

DanielHabenicht commented Sep 24, 2019 •

edited

dominykas commented Sep 24, 2019 •

edited

dominykas commented Sep 24, 2019 •

edited

McRegt commented Oct 3, 2019 •

edited

pvdlg commented Dec 21, 2019 •

edited