zkochan / packages

Zoltan Kochan's npm packages
MIT License
99 stars 26 forks source link

chore(deps): update dependency pnpm to v5 - autoclosed #107

Closed renovate[bot] closed 4 years ago

renovate[bot] commented 4 years ago

This PR contains the following updates:

Package Type Update Change
pnpm (source) devDependencies major 4 -> 5

Release Notes

pnpm/pnpm ### [`v5.1.4`](https://togithub.com/pnpm/pnpm/releases/v5.1.4) [Compare Source](https://togithub.com/pnpm/pnpm/compare/v5.1.3...v5.1.4) ##### Bug Fixes - Fix too long file name issue during write to the content-addressable store ([#​2605](https://togithub.com/pnpm/pnpm/issues/2605)). ### [`v5.1.3`](https://togithub.com/pnpm/pnpm/releases/v5.1.3) [Compare Source](https://togithub.com/pnpm/pnpm/compare/v5.1.2...v5.1.3) ##### Bug Fixes - don't remove authorization headers when redirecting requests to the same host ([#​2602](https://togithub.com/pnpm/pnpm/issues/2602)) ### [`v5.1.2`](https://togithub.com/pnpm/pnpm/releases/v5.1.2) [Compare Source](https://togithub.com/pnpm/pnpm/compare/v5.1.1...v5.1.2) ##### Bug Fixes - fix a regression with node-gyp ([`1dcfecb`](https://togithub.com/pnpm/pnpm/commit/1dcfecb36185b7fd1adfacda4c7ba8387a0689a2)) ### [`v5.1.1`](https://togithub.com/pnpm/pnpm/releases/v5.1.1) [Compare Source](https://togithub.com/pnpm/pnpm/compare/v5.1.0...v5.1.1) ##### Bug Fixes - print a meaningful error when pnpm is executed with Node.js v13.0-v13.6 ([`86d2175`](https://togithub.com/pnpm/pnpm/commit/86d21759da65326d24f77815a1af25be40e6013e)) ### [`v5.1.0`](https://togithub.com/pnpm/pnpm/releases/v5.1.0) [Compare Source](https://togithub.com/pnpm/pnpm/compare/v5.0.2...v5.1.0) ##### Features - [`ffddf34`](https://togithub.com/pnpm/pnpm/commit/ffddf34a8): Add new global option called `--stream`. ([#​2595](https://togithub.com/pnpm/pnpm/issues/2595)) When used, the output from child processes is streamed to the console immediately, prefixed with the originating package directory. This allows output from different packages to be interleaved. - The `run` and `exec` commands may use the `--parallel` option. `--parallel` completely disregards concurrency and topological sorting, running a given script immediately in all matching packages with prefixed streaming output. This is the preferred flag for long-running processes such as watch run over many packages. For example: `pnpm run --parallel watch` PR [#​2599](https://togithub.com/pnpm/pnpm/issues/2599) - Color the child output prefixes ([#​2598](https://togithub.com/pnpm/pnpm/issues/2598)) ![image](https://user-images.githubusercontent.com/1927579/83360236-74485a80-a388-11ea-8648-8dad1998e64e.png) ##### Bug Fixes - A recursive run should not rerun the same package script which started the lifecycle event ([#​2528](https://togithub.com/pnpm/pnpm/issues/2528)). - Fixing a regression on Windows. Fall back to copying if linking fails ([`429c5a5`](https://togithub.com/pnpm/pnpm/commit/429c5a560b7a32b0261e471ece349ec136ab7f4d)) ### [`v5.0.2`](https://togithub.com/pnpm/pnpm/releases/v5.0.2) [Compare Source](https://togithub.com/pnpm/pnpm/compare/v5.0.1...v5.0.2) ##### Major Changes - 🚀 33% faster installation times vs pnpm v4. In some cases, 2 times faster than Yarn v1! ([performance diff of pnpm v4 vs v5](https://togithub.com/pnpm/benchmarks-of-javascript-package-managers/commit/5328f0165628b0ee5e22a8a433357d65bee75d64)) | action | cache | lockfile | node_modules | npm | pnpm | Yarn | Yarn PnP | | ------- | ----- | -------- | ------------ | ----- | ----- | ----- | -------- | | install | | | | 43.3s | 17.5s | 36.7s | 28.6s | | install | ✔ | ✔ | ✔ | 7s | 1.5s | 735ms | n/a | | install | ✔ | ✔ | | 18.3s | 7.8s | 10.5s | 1.8s | | install | ✔ | | | 24.8s | 10.9s | 22.2s | 12.1s | | install | | ✔ | | 23.2s | 15.2s | 22.4s | 13.4s | | install | ✔ | | ✔ | 6.4s | 1.8s | 17.1s | n/a | | install | | ✔ | ✔ | 7.3s | 1.5s | 735ms | n/a | | install | | | ✔ | 6.4s | 3.1s | 33.2s | n/a | | update | n/a | n/a | n/a | 7s | 14.5s | 42.6s | 27.6s | All the benchmarks are [here](https://togithub.com/pnpm/benchmarks-of-javascript-package-managers/tree/5328f0165628b0ee5e22a8a433357d65bee75d64). - A content-addressable filesystem is used to store packages on the disk. pnpm v5 uses a content-addressable filesystem to store all files from all module directories on a disk. If you depend on different versions of lodash, only the files that differ are added to the store. If lodash has 100 files, and a new version has a change only in one of those files, pnpm update will only add 1 new file to the storage. For more info about the structure of this new store, you can check the [GitHub issue about it](https://togithub.com/pnpm/pnpm/issues/2470). This change was inspired by [dupe-krill](https://togithub.com/kornelski/dupe-krill) and the content-addressable storage of Git. - Reduced directory nesting in the virtual store directory. In pnpm v4, if you installed `foo@1.0.0`, it was hard-linked into `node_modules/.pnpm/registry.npmjs.org/foo/1.0.0/`. In pnpm v5, it will be hard-linked into `node_modules/.pnpm/foo@1.0.0/`. This new structure of the virtual store directory drastically reduces the number of directories pnpm has to create. Hence, there are fewer filesystem operations, which improves speed. - `pnpm store usages` removed. This command was using information from the `store.json` files, which is not present in the new content-addressable storage anymore. - The `independent-leaves` setting has been removed. When hoisting was off, it was possible to set the `independent-leaves` setting to `true`. When `true`, leaf dependencies were symlinked directly from the global store. However, we turned hoisting on by default for pnpm v4, so this feature has no future at the moment. - The `resolution-strategy` setting has been removed. By default, the `fewer-dependencies` resolution strategy is used. It was possible to select a `fast` resolution strategy. This setting is deprecated to simplify future improvements to the resolution algorithm. - The store and the modules directory are not locked. We are not using directory locks anymore. So the `--no-lock` option will throw an error. Some users had [issues](https://togithub.com/pnpm/pnpm/issues/594) with locking. We have confidence that pnpm will never leave either node_modules or the store in a broken state, so we removed locking. - `git-checks` is `true` by default. By default, `pnpm publish` will make some checks before actually publishing a new version of your package. The next checks will happen: - The current branch is your publish branch. The publish branch is `master` by default. This is configurable through the `publish-branch` setting. - Your working directory is clean (there are no uncommitted changes). - The branch is up-to-date. If you don't want this checks, run `pnpm publish --no-git-checks` or set this setting to `false` via a `.npmrc` file. - In case of a crash, the debug file will be written to `node_modules/.pnpm-debug.log` (not to `pnpm-debug.log` as in v4 and earlier). ##### Minor Changes - The `link-workspace-packages` setting may now be set to `deep`. When `link-workspace-packages` is set to `deep`, packages from the workspace will be linked even to subdependencies. ### [`v5.0.1`](https://togithub.com/pnpm/pnpm/releases/v5.0.1) [Compare Source](https://togithub.com/pnpm/pnpm/compare/v5.0.0...v5.0.1) ##### Major Changes - 🚀 33% faster installation times vs pnpm v4. In some cases, 2 times faster than Yarn v1! ([performance diff of pnpm v4 vs v5](https://togithub.com/pnpm/benchmarks-of-javascript-package-managers/commit/5328f0165628b0ee5e22a8a433357d65bee75d64)) | action | cache | lockfile | node_modules | npm | pnpm | Yarn | Yarn PnP | | ------- | ----- | -------- | ------------ | ----- | ----- | ----- | -------- | | install | | | | 43.3s | 17.5s | 36.7s | 28.6s | | install | ✔ | ✔ | ✔ | 7s | 1.5s | 735ms | n/a | | install | ✔ | ✔ | | 18.3s | 7.8s | 10.5s | 1.8s | | install | ✔ | | | 24.8s | 10.9s | 22.2s | 12.1s | | install | | ✔ | | 23.2s | 15.2s | 22.4s | 13.4s | | install | ✔ | | ✔ | 6.4s | 1.8s | 17.1s | n/a | | install | | ✔ | ✔ | 7.3s | 1.5s | 735ms | n/a | | install | | | ✔ | 6.4s | 3.1s | 33.2s | n/a | | update | n/a | n/a | n/a | 7s | 14.5s | 42.6s | 27.6s | All the benchmarks are [here](https://togithub.com/pnpm/benchmarks-of-javascript-package-managers/tree/5328f0165628b0ee5e22a8a433357d65bee75d64). - A content-addressable filesystem is used to store packages on the disk. pnpm v5 uses a content-addressable filesystem to store all files from all module directories on a disk. If you depend on different versions of lodash, only the files that differ are added to the store. If lodash has 100 files, and a new version has a change only in one of those files, pnpm update will only add 1 new file to the storage. For more info about the structure of this new store, you can check the [GitHub issue about it](https://togithub.com/pnpm/pnpm/issues/2470). This change was inspired by [dupe-krill](https://togithub.com/kornelski/dupe-krill) and the content-addressable storage of Git. - Reduced directory nesting in the virtual store directory. In pnpm v4, if you installed `foo@1.0.0`, it was hard-linked into `node_modules/.pnpm/registry.npmjs.org/foo/1.0.0/`. In pnpm v5, it will be hard-linked into `node_modules/.pnpm/foo@1.0.0/`. This new structure of the virtual store directory drastically reduces the number of directories pnpm has to create. Hence, there are fewer filesystem operations, which improves speed. - `pnpm store usages` removed. This command was using information from the `store.json` files, which is not present in the new content-addressable storage anymore. - The `independent-leaves` setting has been removed. When hoisting was off, it was possible to set the `independent-leaves` setting to `true`. When `true`, leaf dependencies were symlinked directly from the global store. However, we turned hoisting on by default for pnpm v4, so this feature has no future at the moment. - The `resolution-strategy` setting has been removed. By default, the `fewer-dependencies` resolution strategy is used. It was possible to select a `fast` resolution strategy. This setting is deprecated to simplify future improvements to the resolution algorithm. - The store and the modules directory are not locked. We are not using directory locks anymore. So the `--no-lock` option will throw an error. Some users had [issues](https://togithub.com/pnpm/pnpm/issues/594) with locking. We have confidence that pnpm will never leave either node_modules or the store in a broken state, so we removed locking. - `git-checks` is `true` by default. By default, `pnpm publish` will make some checks before actually publishing a new version of your package. The next checks will happen: - The current branch is your publish branch. The publish branch is `master` by default. This is configurable through the `publish-branch` setting. - Your working directory is clean (there are no uncommitted changes). - The branch is up-to-date. If you don't want this checks, run `pnpm publish --no-git-checks` or set this setting to `false` via a `.npmrc` file. - In case of a crash, the debug file will be written to `node_modules/.pnpm-debug.log` (not to `pnpm-debug.log` as in v4 and earlier). ##### Minor Changes - The `link-workspace-packages` setting may now be set to `deep`. When `link-workspace-packages` is set to `deep`, packages from the workspace will be linked even to subdependencies. ### [`v5.0.0`](https://togithub.com/pnpm/pnpm/releases/v5.0.0) [Compare Source](https://togithub.com/pnpm/pnpm/compare/v4.14.4...v5.0.0) ##### Major Changes - 🚀 33% faster installation times vs pnpm v4. In some cases, 2 times faster than Yarn v1! ([performance diff of pnpm v4 vs v5](https://togithub.com/pnpm/benchmarks-of-javascript-package-managers/commit/5328f0165628b0ee5e22a8a433357d65bee75d64)) | action | cache | lockfile | node_modules | npm | pnpm | Yarn | Yarn PnP | | ------- | ----- | -------- | ------------ | ----- | ----- | ----- | -------- | | install | | | | 43.3s | 17.5s | 36.7s | 28.6s | | install | ✔ | ✔ | ✔ | 7s | 1.5s | 735ms | n/a | | install | ✔ | ✔ | | 18.3s | 7.8s | 10.5s | 1.8s | | install | ✔ | | | 24.8s | 10.9s | 22.2s | 12.1s | | install | | ✔ | | 23.2s | 15.2s | 22.4s | 13.4s | | install | ✔ | | ✔ | 6.4s | 1.8s | 17.1s | n/a | | install | | ✔ | ✔ | 7.3s | 1.5s | 735ms | n/a | | install | | | ✔ | 6.4s | 3.1s | 33.2s | n/a | | update | n/a | n/a | n/a | 7s | 14.5s | 42.6s | 27.6s | All the benchmarks are [here](https://togithub.com/pnpm/benchmarks-of-javascript-package-managers/tree/5328f0165628b0ee5e22a8a433357d65bee75d64). - A content-addressable filesystem is used to store packages on the disk. pnpm v5 uses a content-addressable filesystem to store all files from all module directories on a disk. If you depend on different versions of lodash, only the files that differ are added to the store. If lodash has 100 files, and a new version has a change only in one of those files, pnpm update will only add 1 new file to the storage. For more info about the structure of this new store, you can check the [GitHub issue about it](https://togithub.com/pnpm/pnpm/issues/2470). This change was inspired by [dupe-krill](https://togithub.com/kornelski/dupe-krill) and the content-addressable storage of Git. - Reduced directory nesting in the virtual store directory. In pnpm v4, if you installed `foo@1.0.0`, it was hard-linked into `node_modules/.pnpm/registry.npmjs.org/foo/1.0.0/`. In pnpm v5, it will be hard-linked into `node_modules/.pnpm/foo@1.0.0/`. This new structure of the virtual store directory drastically reduces the number of directories pnpm has to create. Hence, there are fewer filesystem operations, which improves speed. - `pnpm store usages` removed. This command was using information from the `store.json` files, which is not present in the new content-addressable storage anymore. - The `independent-leaves` setting has been removed. When hoisting was off, it was possible to set the `independent-leaves` setting to `true`. When `true`, leaf dependencies were symlinked directly from the global store. However, we turned hoisting on by default for pnpm v4, so this feature has no future at the moment. - The `resolution-strategy` setting has been removed. By default, the `fewer-dependencies` resolution strategy is used. It was possible to select a `fast` resolution strategy. This setting is deprecated to simplify future improvements to the resolution algorithm. - The store and the modules directory are not locked. We are not using directory locks anymore. So the `--no-lock` option will throw an error. Some users had [issues](https://togithub.com/pnpm/pnpm/issues/594) with locking. We have confidence that pnpm will never leave either node_modules or the store in a broken state, so we removed locking. - `git-checks` is `true` by default. By default, `pnpm publish` will make some checks before actually publishing a new version of your package. The next checks will happen: - The current branch is your publish branch. The publish branch is `master` by default. This is configurable through the `publish-branch` setting. - Your working directory is clean (there are no uncommitted changes). - The branch is up-to-date. If you don't want this checks, run `pnpm publish --no-git-checks` or set this setting to `false` via a `.npmrc` file. - In case of a crash, the debug file will be written to `node_modules/.pnpm-debug.log` (not to `pnpm-debug.log` as in v4 and earlier). ##### Minor Changes - The `link-workspace-packages` setting may now be set to `deep`. When `link-workspace-packages` is set to `deep`, packages from the workspace will be linked even to subdependencies.

Renovate configuration

:date: Schedule: "on Friday,every weekend" (UTC).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.



This PR has been generated by WhiteSource Renovate. View repository job log here.