mirrors/pdf.js
1
0
Fork 0
mirror of https://github.com/mozilla/pdf.js.git synced 2025-04-19 14:48:08 +02:00
Code Activity
pdf.js/package-lock.json

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

14771 lines
526 KiB
JSON
Raw Permalink Normal View History

Include `package-lock.json` for reproducible builds
2018-05-20 15:19:49 +02:00
{
"name": "pdf.js",
Update `package-lock.json` to lockfileVersion=3 This reduces the size of the `package-lock.json` file a lot, and given that we recently updated the minimum supported Node.js version to 18 this shouldn't be a problem; please also see - https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json#lockfileversion - https://docs.npmjs.com/cli/v9/using-npm/config?v=true#lockfile-version
2023-05-16 09:50:57 +02:00
"lockfileVersion": 3,
Include `package-lock.json` for reproducible builds
2018-05-20 15:19:49 +02:00
"requires": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"packages": {
"": {
"name": "pdf.js",
"hasInstallScript": true,
"license": "Apache-2.0",
"devDependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/core": "^7.24.8",
"@babel/preset-env": "^7.24.8",
"@babel/runtime": "^7.24.8",
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 16:23:17 +02:00
"@fluent/bundle": "^0.18.0",
Remove the `requestAnimationFrame` work-around in `L10n.prototype.destroy` (PR 18313 follow-up) With `@fluent/dom 0.10.0` just published this work-around is no longer necessary.
2024-06-25 17:23:19 +02:00
"@fluent/dom": "^0.10.0",
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"@jazzer.js/core": "^2.1.0",
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"@metalsmith/layouts": "^2.7.0",
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"@metalsmith/markdown": "^1.10.0",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"autoprefixer": "^10.4.19",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"babel-loader": "^9.1.3",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"caniuse-lite": "^1.0.30001641",
Update npm packages
2023-04-15 22:08:58 +02:00
"canvas": "^2.11.2",
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"core-js": "^3.37.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"cross-env": "^7.0.3",
Update npm packages
2024-03-17 13:50:21 +01:00
"eslint": "^8.57.0",
"eslint-config-prettier": "^9.1.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"eslint-plugin-fetch-options": "^0.0.5",
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"eslint-plugin-html": "^8.1.1",
Update npm packages
2023-12-23 12:29:51 +01:00
"eslint-plugin-import": "^2.29.1",
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"eslint-plugin-jasmine": "^4.2.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"eslint-plugin-json": "^3.1.0",
Update dependencies to the most recent versions
2024-05-23 15:59:27 +02:00
"eslint-plugin-mozilla": "^3.7.4",
Update npm packages
2022-11-27 10:18:30 +01:00
"eslint-plugin-no-unsanitized": "^4.0.2",
Update npm packages
2024-01-20 09:40:33 +01:00
"eslint-plugin-prettier": "^5.1.3",
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"eslint-plugin-sort-exports": "^0.9.1",
Upgrade `eslint-plugin-unicorn` to version 54.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v54.0.0 doesn't indicate any breaking changes that should impact us.
2024-06-18 18:37:32 +02:00
"eslint-plugin-unicorn": "^54.0.0",
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"globals": "^15.8.0",
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"gulp": "^5.0.0",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"gulp-cli": "^3.0.0",
Update `gulp-postcss` to version 10.0.0 This is a major version bump, but the breaking changes don't affect us; please see https://github.com/postcss/gulp-postcss/releases/tag/10.0.0.
2024-02-10 18:16:39 +01:00
"gulp-postcss": "^10.0.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"gulp-rename": "^2.0.0",
Update npm packages
2022-12-25 12:26:23 +01:00
"gulp-replace": "^1.1.4",
Update npm packages The new major version of `gulp-zip` shouldn't be a problem, given the changes listed in https://github.com/sindresorhus/gulp-zip/releases/tag/v6.0.0
2023-11-04 09:30:39 +01:00
"gulp-zip": "^6.0.0",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"highlight.js": "^11.10.0",
Update npm packages
2023-07-23 09:49:53 +02:00
"jasmine": "^5.1.0",
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"jsdoc": "^4.0.3",
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"jstransformer-nunjucks": "^1.2.0",
"metalsmith": "^2.6.3",
"metalsmith-html-relative": "^2.0.1",
Remove the `merge-stream` dependency in favor of the `ordered-read-streams` dependency The `merge-stream` dependency is no longer maintained and doesn't work in combination with Gulp 5 anymore (for more information refer to https://github.com/gulpjs/gulp/issues/2802#issuecomment-2094130656). Fortunately the Gulp team maintains a drop-in replacement dependency called `ordered-read-streams` with the same API as `merge-stream`. Indeed, running all affected Gulp targets and comparing build artifacts with `diff -r <old> <new>` confirms that no unexpected changes are made. Fixes a part of #17922.
2024-05-22 14:11:58 +02:00
"ordered-read-streams": "^2.0.0",
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"path2d": "^0.2.1",
[Editor] Try to make the position of an edited FreeText the more accurated as possible - Take into account the page translation, - Take into account the correct translation for the editor border, - Take into account the position of the first glyph in the annotation, - Take into account the rotation of the editor. Close #16633.
2023-07-05 19:46:21 +02:00
"pngjs": "^7.0.0",
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"postcss": "^8.4.39",
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"postcss-dark-theme-class": "^1.3.0",
Update npm packages
2023-12-23 12:29:51 +01:00
"postcss-dir-pseudo-class": "^8.0.1",
Update dependencies to the most recent versions
2024-06-21 17:09:21 +02:00
"postcss-discard-comments": "^7.0.1",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"postcss-nesting": "^12.1.5",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"prettier": "^3.3.3",
"puppeteer": "^22.13.0",
"stylelint": "^16.7.0",
Update npm packages
2023-12-23 12:29:51 +01:00
"stylelint-prettier": "^5.0.0",
Run minification directly during Webpack building Rather than first building the library and then use Terser "manually" to minify the files, we can utilize a Webpack plugin to combine these steps which helps to simplify the gulpfile.
2024-02-17 16:18:12 +01:00
"terser-webpack-plugin": "^5.3.10",
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"tsc-alias": "^1.8.10",
Update dependencies to the most recent versions
2022-04-02 16:19:17 +02:00
"ttest": "^4.0.0",
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"typescript": "^5.5.3",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"vinyl": "^3.0.0",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"webpack": "^5.93.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"webpack-stream": "^7.0.0",
Update npm packages
2023-05-14 10:12:06 +02:00
"yargs": "^17.7.2"
[api-minor] Update the minimum supported Node.js version to 16 This patch updates the minimum supported environments as follows: - Node.js 16, which was released on 2021-04-20; see https://en.wikipedia.org/wiki/Node.js#Releases Note also that Node.js 14 will very soon reach EOL, and thus no longer receive any security updates.
2023-03-07 12:03:45 +01:00
},
"engines": {
[api-minor] Update the minimum supported Node.js version to 18 This patch updates the minimum supported environments as follows: - Node.js 18, which was released on 2022-04-19; see https://en.wikipedia.org/wiki/Node.js#Releases Note also that Node.js 16 will soon reach EOL, and thus no longer receive any security updates.
2023-04-05 10:40:19 +02:00
"node": ">=18"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node_modules/@aashutoshrathi/word-wrap": {
"version": "1.2.6",
"resolved": "https://registry.npmjs.org/@aashutoshrathi/word-wrap/-/word-wrap-1.2.6.tgz",
"integrity": "sha512-1Yjs2SvM8TflER/OD3cOjhWWOZb58A2t7wpE2S9XfBYTiIl+XFhQG2bjy4Pu1I+EAlCNUzRDYDdFwFYUKvXcIA==",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
Update npm packages
2022-02-06 11:24:14 +01:00
"node_modules/@ampproject/remapping": {
Update npm packages
2023-03-12 10:27:52 +01:00
"version": "2.2.0",
"resolved": "https://registry.npmjs.org/@ampproject/remapping/-/remapping-2.2.0.tgz",
"integrity": "sha512-qRmjj8nj9qmLTQXXmaR1cck3UXSRMPrbsLJAasZpF+t3riI71BXed5ebIOYwQntykeZuhjsdweEc9BxH5Jc26w==",
"dev": true,
"dependencies": {
"@jridgewell/gen-mapping": "^0.1.0",
"@jridgewell/trace-mapping": "^0.3.9"
},
"engines": {
"node": ">=6.0.0"
}
},
"node_modules/@ampproject/remapping/node_modules/@jridgewell/gen-mapping": {
"version": "0.1.1",
"resolved": "https://registry.npmjs.org/@jridgewell/gen-mapping/-/gen-mapping-0.1.1.tgz",
"integrity": "sha512-sQXCasFk+U8lWYEe66WxRDOE9PjVz4vSM51fTu3Hw+ClTpUSQb718772vH3pyS5pShp6lvQM7SxgIDXXXmOX7w==",
Update npm packages
2022-02-06 11:24:14 +01:00
"dev": true,
"dependencies": {
Update npm packages
2023-03-12 10:27:52 +01:00
"@jridgewell/set-array": "^1.0.0",
"@jridgewell/sourcemap-codec": "^1.4.10"
Update npm packages
2022-02-06 11:24:14 +01:00
},
"engines": {
"node": ">=6.0.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/code-frame": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.24.7.tgz",
"integrity": "sha512-BcYH1CVJBO9tvyIZ2jVeXgSIMvGZ2FDRvDdOIVQyuklNKSsx+eppDEBq/g47Ayw+RqNFE+URvOShmf+f/qwAlA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/highlight": "^7.24.7",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"picocolors": "^1.0.0"
Update npm packages
2022-01-09 10:05:52 +01:00
},
"engines": {
"node": ">=6.9.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/@babel/compat-data": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/compat-data/-/compat-data-7.24.8.tgz",
"integrity": "sha512-c4IM7OTg6k1Q+AJ153e2mc2QVTezTwnb4VzquwcyiEzGnW0Kedv4do/TrkU98qPeC5LNiMt/QXwIjzYXLBpyZg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/core": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/core/-/core-7.24.8.tgz",
"integrity": "sha512-6AWcmZC/MZCO0yKys4uhg5NlxL0ESF3K6IAaoQ+xSXvPyPyxNWRafP+GDbI88Oh68O7QkJgmEtedWPM9U0pZNg==",
Update npm packages
2022-01-09 10:05:52 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2022-01-09 10:05:52 +01:00
"dependencies": {
Update npm packages
2023-03-12 10:27:52 +01:00
"@ampproject/remapping": "^2.2.0",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/code-frame": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/generator": "^7.24.8",
"@babel/helper-compilation-targets": "^7.24.8",
"@babel/helper-module-transforms": "^7.24.8",
"@babel/helpers": "^7.24.8",
"@babel/parser": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/template": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/traverse": "^7.24.8",
"@babel/types": "^7.24.8",
Update dependencies to the most recent versions
2023-10-14 13:44:21 +02:00
"convert-source-map": "^2.0.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"debug": "^4.1.0",
"gensync": "^1.0.0-beta.2",
Update npm packages
2023-09-03 09:59:08 +02:00
"json5": "^2.2.3",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"semver": "^6.3.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"funding": {
"type": "opencollective",
"url": "https://opencollective.com/babel"
}
},
"node_modules/@babel/core/node_modules/semver": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"version": "6.3.1",
"resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz",
"integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"bin": {
"semver": "bin/semver.js"
}
},
"node_modules/@babel/generator": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/generator/-/generator-7.24.8.tgz",
"integrity": "sha512-47DG+6F5SzOi0uEvK4wMShmn5yY0mVjVJoWTphdY2B4Rx9wHgjK7Yhtr0ru6nE+sn0v38mzrWOlah0p/YlHHOQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/types": "^7.24.8",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@jridgewell/gen-mapping": "^0.3.5",
"@jridgewell/trace-mapping": "^0.3.25",
Update dependencies to the most recent versions There are two notable changes here: - `dommatrix` is a major version upgrade, but looking through the commit history of their `package.json` file at https://github.com/thednp/dommatrix/commits/master/package.json (due to the lack of a changelog) I couldn't find any breaking changes. - `es-module-shims` is a regular update, but it was previously pinned for causing intermittent breakage when running the unit tests in a browser manually. Fortunately this cannot be reproduced anymore with the most recent version, so we can also put the caret back now.
2022-04-30 19:56:10 +02:00
"jsesc": "^2.5.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-annotate-as-pure": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-annotate-as-pure/-/helper-annotate-as-pure-7.24.7.tgz",
"integrity": "sha512-BaDeOonYvhdKw+JoMVkAixAAJzG2jVPIwWoKBPdYuY9b452e2rPuI9QPYh3KpofZ3pW2akOmwZLOiOsHMiqRAg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-builder-binary-assignment-operator-visitor": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-builder-binary-assignment-operator-visitor/-/helper-builder-binary-assignment-operator-visitor-7.24.7.tgz",
"integrity": "sha512-xZeCVVdwb4MsDBkkyZ64tReWYrLRHlMN72vP7Bdm3OUOuyFZExhsHUUnuWnm2/XOlAJzR0LfPpB56WXZn0X/lA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/traverse": "^7.24.7",
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-compilation-targets": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/helper-compilation-targets/-/helper-compilation-targets-7.24.8.tgz",
"integrity": "sha512-oU+UoqCHdp+nWVDkpldqIQL/i/bvAv53tRqLG/s+cOXxe66zOYLU7ar/Xs3LdmBihrUMEUhwu6dMZwbNOYDwvw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/compat-data": "^7.24.8",
"@babel/helper-validator-option": "^7.24.8",
"browserslist": "^4.23.1",
Update npm packages
2022-12-25 12:26:23 +01:00
"lru-cache": "^5.1.1",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"semver": "^6.3.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
Update npm packages
2022-12-25 12:26:23 +01:00
"node_modules/@babel/helper-compilation-targets/node_modules/lru-cache": {
"version": "5.1.1",
"resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-5.1.1.tgz",
"integrity": "sha512-KpNARQA3Iwv+jTA0utUVVbrh+Jlrr1Fv0e56GGzAFOXN7dk/FviaDW8LHmK52DlcH4WP2n6gI8vN1aesBFgo9w==",
"dev": true,
"dependencies": {
"yallist": "^3.0.2"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/helper-compilation-targets/node_modules/semver": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"version": "6.3.1",
"resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz",
"integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"bin": {
"semver": "bin/semver.js"
}
},
"node_modules/@babel/helper-create-class-features-plugin": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-create-class-features-plugin/-/helper-create-class-features-plugin-7.24.7.tgz",
"integrity": "sha512-kTkaDl7c9vO80zeX1rJxnuRpEsD5tA81yh11X1gQo+PhSti3JS+7qeZo9U4RHobKRiFPKaGK3svUAeb8D0Q7eg==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "MIT",
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-annotate-as-pure": "^7.24.7",
"@babel/helper-environment-visitor": "^7.24.7",
"@babel/helper-function-name": "^7.24.7",
"@babel/helper-member-expression-to-functions": "^7.24.7",
"@babel/helper-optimise-call-expression": "^7.24.7",
"@babel/helper-replace-supers": "^7.24.7",
"@babel/helper-skip-transparent-expression-wrappers": "^7.24.7",
"@babel/helper-split-export-declaration": "^7.24.7",
Update npm packages
2023-09-03 09:59:08 +02:00
"semver": "^6.3.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/helper-create-class-features-plugin/node_modules/semver": {
Update npm packages
2023-09-03 09:59:08 +02:00
"version": "6.3.1",
"resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz",
"integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "ISC",
Update npm packages
2023-05-28 09:39:34 +02:00
"bin": {
"semver": "bin/semver.js"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/helper-create-regexp-features-plugin": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-create-regexp-features-plugin/-/helper-create-regexp-features-plugin-7.24.7.tgz",
"integrity": "sha512-03TCmXy2FtXJEZfbXDTSqq1fRJArk7lX9DOFC/47VthYcxyIOx+eXQmdo6DOQvrbpIix+KfXwvuXdFDZHxt+rA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-annotate-as-pure": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"regexpu-core": "^5.3.1",
Update dependencies to the most recent versions
2023-11-11 15:57:28 +01:00
"semver": "^6.3.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/helper-create-regexp-features-plugin/node_modules/semver": {
Fix dependency vulnerabilities with `npm audit fix`
2023-10-14 13:46:57 +02:00
"version": "6.3.1",
"resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz",
"integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
"bin": {
"semver": "bin/semver.js"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/helper-define-polyfill-provider": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "0.6.1",
"resolved": "https://registry.npmjs.org/@babel/helper-define-polyfill-provider/-/helper-define-polyfill-provider-0.6.1.tgz",
"integrity": "sha512-o7SDgTJuvx5vLKD6SFvkydkSMBvahDKGiNJzG22IZYXhiqoe9efY7zocICBgzHV4IRg5wdgl2nEL/tulKIEIbA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"@babel/helper-compilation-targets": "^7.22.6",
"@babel/helper-plugin-utils": "^7.22.5",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"debug": "^4.1.1",
"lodash.debounce": "^4.0.8",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"resolve": "^1.14.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependencies": {
Update npm packages
2023-08-19 09:08:11 +02:00
"@babel/core": "^7.4.0 || ^8.0.0-0 <8.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update npm packages
2021-12-26 11:09:29 +01:00
"node_modules/@babel/helper-environment-visitor": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-environment-visitor/-/helper-environment-visitor-7.24.7.tgz",
"integrity": "sha512-DoiN84+4Gnd0ncbBOM9AZENV4a5ZiL39HYMyZJGZ/AZEykHYdJw0wW3kdcsh9/Kn+BRXHLkkklZ51ecPKmI1CQ==",
Update npm packages
2021-12-26 11:09:29 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"dependencies": {
"@babel/types": "^7.24.7"
},
Update npm packages
2021-12-26 11:09:29 +01:00
"engines": {
"node": ">=6.9.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/helper-function-name": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-function-name/-/helper-function-name-7.24.7.tgz",
"integrity": "sha512-FyoJTsj/PEUWu1/TYRiXTIHc8lbw+TDYkZuoE43opPS5TrI7MyONBE1oNvfguEXAD9yhQRrVBnXdXzSLQl9XnA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/template": "^7.24.7",
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-hoist-variables": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-hoist-variables/-/helper-hoist-variables-7.24.7.tgz",
"integrity": "sha512-MJJwhkoGy5c4ehfoRyrJ/owKeMl19U54h27YYftT0o2teQ3FJ3nQUf/I3LlJsX4l3qlw7WRXUmiyajvHXoTubQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-member-expression-to-functions": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-member-expression-to-functions/-/helper-member-expression-to-functions-7.24.7.tgz",
"integrity": "sha512-LGeMaf5JN4hAT471eJdBs/GK1DoYIJ5GCtZN/EsL6KUiiDZOvO/eKE11AMZJa2zP4zk4qe9V2O/hxAmkRc8p6w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/traverse": "^7.24.7",
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-module-imports": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-module-imports/-/helper-module-imports-7.24.7.tgz",
"integrity": "sha512-8AyH3C+74cgCVVXow/myrynrAGv+nTVg5vKu2nZph9x7RcRwzmh0VFallJuFTZ9mx6u4eSdXZfcOzSqTUm0HCA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/traverse": "^7.24.7",
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-module-transforms": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/helper-module-transforms/-/helper-module-transforms-7.24.8.tgz",
"integrity": "sha512-m4vWKVqvkVAWLXfHCCfff2luJj86U+J0/x+0N3ArG/tP0Fq7zky2dYwMbtPmkc/oulkkbjdL3uWzuoBwQ8R00Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-environment-visitor": "^7.24.7",
"@babel/helper-module-imports": "^7.24.7",
"@babel/helper-simple-access": "^7.24.7",
"@babel/helper-split-export-declaration": "^7.24.7",
"@babel/helper-validator-identifier": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
},
"peerDependencies": {
"@babel/core": "^7.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/@babel/helper-optimise-call-expression": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-optimise-call-expression/-/helper-optimise-call-expression-7.24.7.tgz",
"integrity": "sha512-jKiTsW2xmWwxT1ixIdfXUZp+P5yURx2suzLZr5Hi64rURpDYdMW0pv+Uf17EYk2Rd428Lx4tLsnjGJzYKDM/6A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-plugin-utils": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/helper-plugin-utils/-/helper-plugin-utils-7.24.8.tgz",
"integrity": "sha512-FFWx5142D8h2Mgr/iPVGH5G7w6jDn4jUSpZTyDnQO0Yn7Ks2Kuz6Pci8H6MPCoUJegd/UZQ3tAvfLCxQSnWWwg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-remap-async-to-generator": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-remap-async-to-generator/-/helper-remap-async-to-generator-7.24.7.tgz",
"integrity": "sha512-9pKLcTlZ92hNZMQfGCHImUpDOlAgkkpqalWEeftW5FBya75k8Li2ilerxkM/uBEj01iBZXcCIB/bwvDYgWyibA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-annotate-as-pure": "^7.24.7",
"@babel/helper-environment-visitor": "^7.24.7",
"@babel/helper-wrap-function": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
Update npm packages
2022-07-10 10:43:08 +02:00
},
"peerDependencies": {
"@babel/core": "^7.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/@babel/helper-replace-supers": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-replace-supers/-/helper-replace-supers-7.24.7.tgz",
"integrity": "sha512-qTAxxBM81VEyoAY0TtLrx1oAEJc09ZK67Q9ljQToqCnA+55eNwCORaxlKyu+rNfX86o8OXRUSNUnrtsAZXM9sg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-environment-visitor": "^7.24.7",
"@babel/helper-member-expression-to-functions": "^7.24.7",
"@babel/helper-optimise-call-expression": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
Update npm packages
2023-09-03 09:59:08 +02:00
},
"peerDependencies": {
"@babel/core": "^7.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/@babel/helper-simple-access": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-simple-access/-/helper-simple-access-7.24.7.tgz",
"integrity": "sha512-zBAIvbCMh5Ts+b86r/CjU+4XGYIs+R1j951gxI3KmmxBMhCg4oQMsv6ZXQ64XOm/cvzfU1FmoCyt6+owc5QMYg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/traverse": "^7.24.7",
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-skip-transparent-expression-wrappers": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-skip-transparent-expression-wrappers/-/helper-skip-transparent-expression-wrappers-7.24.7.tgz",
"integrity": "sha512-IO+DLT3LQUElMbpzlatRASEyQtfhSE0+m465v++3jyyXeBTBUjtVZg28/gHeV5mrTJqvEKhKroBGAvhW+qPHiQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/traverse": "^7.24.7",
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-split-export-declaration": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-split-export-declaration/-/helper-split-export-declaration-7.24.7.tgz",
"integrity": "sha512-oy5V7pD+UvfkEATUKvIjvIAH/xCzfsFVw7ygW2SI6NClZzquT+mwdTfgfdbUiceh6iQO0CHtCPsyze/MZ2YbAA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
Update npm packages
2022-08-07 10:20:21 +02:00
"node_modules/@babel/helper-string-parser": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/helper-string-parser/-/helper-string-parser-7.24.8.tgz",
"integrity": "sha512-pO9KhhRcuUyGnJWwyEgnRJTSIZHiT+vMD0kPeD+so0l7mxkMT19g3pjY9GTnHySck/hDzq+dtW/4VgnMkippsQ==",
Update npm packages
2022-08-07 10:20:21 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2022-08-07 10:20:21 +02:00
"engines": {
"node": ">=6.9.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/helper-validator-identifier": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.24.7.tgz",
"integrity": "sha512-rR+PBcQ1SMQDDyF6X0wxtG8QyLCgUB0eRAGguqRLfkCA87l7yAP7ehq8SNj96OOGTO8OBV70KhuFYcIkHXOg0w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-validator-option": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/helper-validator-option/-/helper-validator-option-7.24.8.tgz",
"integrity": "sha512-xb8t9tD1MHLungh/AIoWYN+gVHaB9kwlu8gffXGSt3FFEIT7RjS+xWbc2vUD1UTZdIpKj/ab3rdqJ7ufngyi2Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helper-wrap-function": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/helper-wrap-function/-/helper-wrap-function-7.24.7.tgz",
"integrity": "sha512-N9JIYk3TD+1vq/wn77YnJOqMtfWhNewNE+DJV4puD2X7Ew9J4JvrzrFDfTfyv5EgEXVy9/Wt8QiOErzEmv5Ifw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-function-name": "^7.24.7",
"@babel/template": "^7.24.7",
"@babel/traverse": "^7.24.7",
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/helpers": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/helpers/-/helpers-7.24.8.tgz",
"integrity": "sha512-gV2265Nkcz7weJJfvDoAEVzC1e2OTDpkGbEsebse8koXUJUXPsCMi7sRo/+SPMuMZ9MtUPnGwITTnQnU5YjyaQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/template": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/types": "^7.24.8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/highlight": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/highlight/-/highlight-7.24.7.tgz",
"integrity": "sha512-EStJpq4OuY8xYfhGVXngigBJRWxftKX9ksiGDnmlY3o7B/V7KIAc9X4oiK87uPJSc/vs5L869bem5fhZa8caZw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-validator-identifier": "^7.24.7",
Update npm packages
2023-08-19 09:08:11 +02:00
"chalk": "^2.4.2",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"js-tokens": "^4.0.0",
"picocolors": "^1.0.0"
Update npm packages
2022-01-09 10:05:52 +01:00
},
"engines": {
"node": ">=6.9.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/@babel/parser": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/parser/-/parser-7.24.8.tgz",
"integrity": "sha512-WzfbgXOkGzZiXXCqk43kKwZjzwx4oulxZi3nq2TYL9mOjQv6kYwul9mz6ID36njuL7Xkp6nJEfok848Zj10j/w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"bin": {
"parser": "bin/babel-parser.js"
},
"engines": {
"node": ">=6.0.0"
}
},
Update dependencies to the most recent versions
2024-04-11 15:40:38 +02:00
"node_modules/@babel/plugin-bugfix-firefox-class-in-computed-class-key": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-bugfix-firefox-class-in-computed-class-key/-/plugin-bugfix-firefox-class-in-computed-class-key-7.24.7.tgz",
"integrity": "sha512-TiT1ss81W80eQsN+722OaeQMY/G4yTb4G9JrqeiDADs3N8lbPMGldWi9x8tyqCW5NLx1Jh2AvkE6r6QvEltMMQ==",
Update dependencies to the most recent versions
2024-04-11 15:40:38 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update dependencies to the most recent versions
2024-04-11 15:40:38 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-environment-visitor": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Update dependencies to the most recent versions
2024-04-11 15:40:38 +02:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression/-/plugin-bugfix-safari-id-destructuring-collision-in-function-expression-7.24.7.tgz",
"integrity": "sha512-unaQgZ/iRu/By6tsjMZzpeBZjChYfLYry6HrEXPoz3KmfF0sVBQ1l8zKMQ4xRGLWVsjuvB8nQfjNP/DcfEOCsg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0"
}
},
"node_modules/@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining/-/plugin-bugfix-v8-spread-parameters-in-optional-chaining-7.24.7.tgz",
"integrity": "sha512-+izXIbke1T33mY4MSNnrqhPXDz01WYhEf3yF5NbnUtkiNnm+XBZJl3kNfoK6NKmYlz/D07+l2GWVK/QfDkNCuQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
"@babel/helper-skip-transparent-expression-wrappers": "^7.24.7",
"@babel/plugin-transform-optional-chaining": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.13.0"
}
},
Update dependencies to the most recent versions
2023-11-11 15:57:28 +01:00
"node_modules/@babel/plugin-bugfix-v8-static-class-fields-redefine-readonly": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-bugfix-v8-static-class-fields-redefine-readonly/-/plugin-bugfix-v8-static-class-fields-redefine-readonly-7.24.7.tgz",
"integrity": "sha512-utA4HuR6F4Vvcr+o4DnjL8fCOlgRFGbeeBEGNg3ZTrLFw6VWG5XmUrvcQ0FjIYMU2ST4XcR2Wsp7t9qOAPnxMg==",
Update dependencies to the most recent versions
2023-11-11 15:57:28 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update dependencies to the most recent versions
2023-11-11 15:57:28 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-environment-visitor": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Update dependencies to the most recent versions
2023-11-11 15:57:28 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-proposal-private-property-in-object": {
Update npm packages
2023-06-11 11:30:39 +02:00
"version": "7.21.0-placeholder-for-preset-env.2",
"resolved": "https://registry.npmjs.org/@babel/plugin-proposal-private-property-in-object/-/plugin-proposal-private-property-in-object-7.21.0-placeholder-for-preset-env.2.tgz",
"integrity": "sha512-SOSkfJDddaM7mak6cPEpswyTRnuRltl429hMraQEglW+OkovnCzsiszTmsrlY//qLFjCpQDFRvjdm2wA5pPm9w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-async-generators": {
"version": "7.8.4",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-async-generators/-/plugin-syntax-async-generators-7.8.4.tgz",
"integrity": "sha512-tycmZxkGfZaxhMRbXlPXuVFpdWlXpir2W4AMhSJgRKzk/eDlIXOhb2LHWoLpDF7TEHylV5zNhykX6KAgHJmTNw==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.8.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-class-properties": {
"version": "7.12.13",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-class-properties/-/plugin-syntax-class-properties-7.12.13.tgz",
"integrity": "sha512-fm4idjKla0YahUNgFNLCB0qySdsoPiZP3iQE3rky0mBUtMZ23yDJ9SJdg6dXTSDnulOVqiF3Hgr9nbXvXTQZYA==",
"dev": true,
"dependencies": {
"@babel/helper-plugin-utils": "^7.12.13"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-class-static-block": {
"version": "7.14.5",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-class-static-block/-/plugin-syntax-class-static-block-7.14.5.tgz",
"integrity": "sha512-b+YyPmr6ldyNnM6sqYeMWE+bgJcJpO6yS4QD7ymxgH34GBPNDM/THBh8iunyvKIZztiwLH4CJZ0RxTk9emgpjw==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.14.5"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-dynamic-import": {
"version": "7.8.3",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-dynamic-import/-/plugin-syntax-dynamic-import-7.8.3.tgz",
"integrity": "sha512-5gdGbFon+PszYzqs83S3E5mpi7/y/8M9eC90MRTZfduQOYW76ig6SOSPNe41IG5LoP3FGBn2N0RjVDSQiS94kQ==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.8.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-export-namespace-from": {
"version": "7.8.3",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-export-namespace-from/-/plugin-syntax-export-namespace-from-7.8.3.tgz",
"integrity": "sha512-MXf5laXo6c1IbEbegDmzGPwGNTsHZmEy6QGznu5Sh2UCWvueywb2ee+CCE4zQiZstxU9BMoQO9i6zUFSY0Kj0Q==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.8.3"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2022-05-29 09:28:39 +02:00
"node_modules/@babel/plugin-syntax-import-assertions": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-import-assertions/-/plugin-syntax-import-assertions-7.24.7.tgz",
"integrity": "sha512-Ec3NRUMoi8gskrkBe3fNmEQfxDvY8bgfQpz6jlk/41kX9eUjvpyqWU7PBP/pLAvMaSQjbMNKJmvX57jP+M6bPg==",
Update npm packages
2022-05-29 09:28:39 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2022-05-29 09:28:39 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Update npm packages
2022-05-29 09:28:39 +02:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/plugin-syntax-import-attributes": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-import-attributes/-/plugin-syntax-import-attributes-7.24.7.tgz",
"integrity": "sha512-hbX+lKKeUMGihnK8nvKqmXBInriT3GVjzXKFriV3YC6APGxMbP8RZNFwy91+hocLXq90Mta+HshoB31802bb8A==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Update npm packages
2023-05-28 09:39:34 +02:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-14 10:12:06 +02:00
"node_modules/@babel/plugin-syntax-import-meta": {
"version": "7.10.4",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-import-meta/-/plugin-syntax-import-meta-7.10.4.tgz",
"integrity": "sha512-Yqfm+XDx0+Prh3VSeEQCPU81yC+JWZ2pDPFSS4ZdpfZhp4MkFMaDC1UqseovEKwSUpnIL7+vK+Clp7bfh0iD7g==",
"dev": true,
"dependencies": {
"@babel/helper-plugin-utils": "^7.10.4"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-syntax-json-strings": {
"version": "7.8.3",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-json-strings/-/plugin-syntax-json-strings-7.8.3.tgz",
"integrity": "sha512-lY6kdGpWHvjoe2vk4WrAapEuBR69EMxZl+RoGRhrFGNYVK8mOPAW8VfbT/ZgrFbXlDNiiaxQnAtgVCZ6jv30EA==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.8.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-logical-assignment-operators": {
"version": "7.10.4",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-logical-assignment-operators/-/plugin-syntax-logical-assignment-operators-7.10.4.tgz",
"integrity": "sha512-d8waShlpFDinQ5MtvGU9xDAOzKH47+FFoney2baFIoMr952hKOLp1HR7VszoZvOsV/4+RRszNY7D17ba0te0ig==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.10.4"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-nullish-coalescing-operator": {
"version": "7.8.3",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-nullish-coalescing-operator/-/plugin-syntax-nullish-coalescing-operator-7.8.3.tgz",
"integrity": "sha512-aSff4zPII1u2QD7y+F8oDsz19ew4IGEJg9SVW+bqwpwtfFleiQDMdzA/R+UlWDzfnHFCxxleFT0PMIrR36XLNQ==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.8.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-numeric-separator": {
"version": "7.10.4",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-numeric-separator/-/plugin-syntax-numeric-separator-7.10.4.tgz",
"integrity": "sha512-9H6YdfkcK/uOnY/K7/aA2xpzaAgkQn37yzWUMRK7OaPOqOpGS1+n0H5hxT9AUw9EsSjPW8SVyMJwYRtWs3X3ug==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.10.4"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-object-rest-spread": {
"version": "7.8.3",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-object-rest-spread/-/plugin-syntax-object-rest-spread-7.8.3.tgz",
"integrity": "sha512-XoqMijGZb9y3y2XskN+P1wUGiVwWZ5JmoDRwx5+3GmEplNyVM2s2Dg8ILFQm8rWM48orGy5YpI5Bl8U1y7ydlA==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.8.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-optional-catch-binding": {
"version": "7.8.3",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-optional-catch-binding/-/plugin-syntax-optional-catch-binding-7.8.3.tgz",
"integrity": "sha512-6VPD0Pc1lpTqw0aKoeRTMiB+kWhAoT24PA+ksWSBrFtl5SIRVpZlwN3NNPQjehA2E/91FV3RjLWoVTglWcSV3Q==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.8.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-optional-chaining": {
"version": "7.8.3",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-optional-chaining/-/plugin-syntax-optional-chaining-7.8.3.tgz",
"integrity": "sha512-KoK9ErH1MBlCPxV0VANkXW2/dw4vlbGDrFgz8bmUsBGYkFRcbRwMh6cIJubdPrkxRwuGdtCk0v/wPTKbQgBjkg==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.8.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-private-property-in-object": {
"version": "7.14.5",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-private-property-in-object/-/plugin-syntax-private-property-in-object-7.14.5.tgz",
"integrity": "sha512-0wVnp9dxJ72ZUJDV27ZfbSj6iHLoytYZmh3rFcxNnvsJF3ktkzLDZPy/mA17HGsaQT3/DQsWYX1f1QGWkCoVUg==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/helper-plugin-utils": "^7.14.5"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-syntax-top-level-await": {
"version": "7.14.5",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-top-level-await/-/plugin-syntax-top-level-await-7.14.5.tgz",
"integrity": "sha512-hx++upLv5U1rgYfwe1xBQUhRmU41NEvpUvrp8jkrSCdvGSnM5/qdRMtylJ6PG5OFkBaHkbTAKTnd3/YyESRHFw==",
"dev": true,
"dependencies": {
"@babel/helper-plugin-utils": "^7.14.5"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/plugin-syntax-unicode-sets-regex": {
"version": "7.18.6",
"resolved": "https://registry.npmjs.org/@babel/plugin-syntax-unicode-sets-regex/-/plugin-syntax-unicode-sets-regex-7.18.6.tgz",
"integrity": "sha512-727YkEAPwSIQTv5im8QHz3upqp92JTWhidIC81Tdx4VJYIte/VndKf1qKrfnnhPLiPghStWfvC/iFaMCQu7Nqg==",
"dev": true,
"dependencies": {
"@babel/helper-create-regexp-features-plugin": "^7.18.6",
"@babel/helper-plugin-utils": "^7.18.6"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-transform-arrow-functions": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-arrow-functions/-/plugin-transform-arrow-functions-7.24.7.tgz",
"integrity": "sha512-Dt9LQs6iEY++gXUwY03DNFat5C2NbO48jj+j/bSAz6b3HgPs39qcPiYt77fDObIcFwj3/C2ICX9YMwGflUoSHQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/plugin-transform-async-generator-functions": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-async-generator-functions/-/plugin-transform-async-generator-functions-7.24.7.tgz",
"integrity": "sha512-o+iF77e3u7ZS4AoAuJvapz9Fm001PuD2V3Lp6OSE4FYQke+cSewYtnek+THqGRWyQloRCyvWL1OkyfNEl9vr/g==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-environment-visitor": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7",
"@babel/helper-remap-async-to-generator": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-async-generators": "^7.8.4"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-transform-async-to-generator": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-async-to-generator/-/plugin-transform-async-to-generator-7.24.7.tgz",
"integrity": "sha512-SQY01PcJfmQ+4Ash7NE+rpbLFbmqA2GPIgqzxfFTL4t1FKRq4zTms/7htKpoCUI9OcFYgzqfmCdH53s6/jn5fA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-module-imports": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7",
"@babel/helper-remap-async-to-generator": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-block-scoped-functions": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-block-scoped-functions/-/plugin-transform-block-scoped-functions-7.24.7.tgz",
"integrity": "sha512-yO7RAz6EsVQDaBH18IDJcMB1HnrUn2FJ/Jslc/WtPPWcjhpUJXU/rjbwmluzp7v/ZzWcEhTMXELnnsz8djWDwQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-block-scoping": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-block-scoping/-/plugin-transform-block-scoping-7.24.7.tgz",
"integrity": "sha512-Nd5CvgMbWc+oWzBsuaMcbwjJWAcp5qzrbg69SZdHSP7AMY0AbWFqFO0WTFCA1jxhMCwodRwvRec8k0QUbZk7RQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/plugin-transform-class-properties": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-class-properties/-/plugin-transform-class-properties-7.24.7.tgz",
"integrity": "sha512-vKbfawVYayKcSeSR5YYzzyXvsDFWU2mD8U5TFeXtbCPLFUqe7GyCgvO6XDHzje862ODrOwy6WCPmKeWHbCFJ4w==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-create-class-features-plugin": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Update npm packages
2023-05-28 09:39:34 +02:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-class-static-block": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-class-static-block/-/plugin-transform-class-static-block-7.24.7.tgz",
"integrity": "sha512-HMXK3WbBPpZQufbMG4B46A90PkuuhN9vBCb5T8+VAHqvAqvcLi+2cKoukcpmUYkszLhScU3l1iudhrks3DggRQ==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-create-class-features-plugin": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-class-static-block": "^7.14.5"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.12.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-transform-classes": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-classes/-/plugin-transform-classes-7.24.8.tgz",
"integrity": "sha512-VXy91c47uujj758ud9wx+OMgheXm4qJfyhj1P18YvlrQkNOSrwsteHk+EFS3OMGfhMhpZa0A+81eE7G4QC+3CA==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "MIT",
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-annotate-as-pure": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/helper-compilation-targets": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-environment-visitor": "^7.24.7",
"@babel/helper-function-name": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/helper-plugin-utils": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-replace-supers": "^7.24.7",
"@babel/helper-split-export-declaration": "^7.24.7",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"globals": "^11.1.0"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-classes/node_modules/globals": {
"version": "11.12.0",
"resolved": "https://registry.npmjs.org/globals/-/globals-11.12.0.tgz",
"integrity": "sha512-WOBp/EEGUiIsJSp7wcv/y6MO+lV9UoncWqxuFfm8eBwzWNgyfBd6Gz+IeKQ9jCmyhoH99g15M3T+QaVHFjizVA==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=4"
}
},
"node_modules/@babel/plugin-transform-computed-properties": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-computed-properties/-/plugin-transform-computed-properties-7.24.7.tgz",
"integrity": "sha512-25cS7v+707Gu6Ds2oY6tCkUwsJ9YIDbggd9+cu9jzzDgiNq7hR/8dkzxWfKWnTic26vsI3EsCXNd4iEB6e8esQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
"@babel/template": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-destructuring": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-destructuring/-/plugin-transform-destructuring-7.24.8.tgz",
"integrity": "sha512-36e87mfY8TnRxc7yc6M9g9gOB7rKgSahqkIKwLpz4Ppk2+zC2Cy1is0uwtuSG6AE4zlTOUa+7JGz9jCJGLqQFQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/helper-plugin-utils": "^7.24.8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-dotall-regex": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-dotall-regex/-/plugin-transform-dotall-regex-7.24.7.tgz",
"integrity": "sha512-ZOA3W+1RRTSWvyqcMJDLqbchh7U4NRGqwRfFSVbOLS/ePIP4vHB5e8T8eXcuqyN1QkgKyj5wuW0lcS85v4CrSw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-create-regexp-features-plugin": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-duplicate-keys": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-duplicate-keys/-/plugin-transform-duplicate-keys-7.24.7.tgz",
"integrity": "sha512-JdYfXyCRihAe46jUIliuL2/s0x0wObgwwiGxw/UbgJBr20gQBThrokO4nYKgWkD7uBaqM7+9x5TU7NkExZJyzw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/plugin-transform-dynamic-import": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-dynamic-import/-/plugin-transform-dynamic-import-7.24.7.tgz",
"integrity": "sha512-sc3X26PhZQDb3JhORmakcbvkeInvxz+A8oda99lj7J60QRuPZvNAk9wQlTBS1ZynelDrDmTU4pw1tyc5d5ZMUg==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-dynamic-import": "^7.8.3"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-transform-exponentiation-operator": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-exponentiation-operator/-/plugin-transform-exponentiation-operator-7.24.7.tgz",
"integrity": "sha512-Rqe/vSc9OYgDajNIK35u7ot+KeCoetqQYFXM4Epf7M7ez3lWlOjrDjrwMei6caCVhfdw+mIKD4cgdGNy5JQotQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-builder-binary-assignment-operator-visitor": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/plugin-transform-export-namespace-from": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-export-namespace-from/-/plugin-transform-export-namespace-from-7.24.7.tgz",
"integrity": "sha512-v0K9uNYsPL3oXZ/7F9NNIbAj2jv1whUEtyA6aujhekLs56R++JDQuzRcP2/z4WX5Vg/c5lE9uWZA0/iUoFhLTA==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-export-namespace-from": "^7.8.3"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-transform-for-of": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-for-of/-/plugin-transform-for-of-7.24.7.tgz",
"integrity": "sha512-wo9ogrDG1ITTTBsy46oGiN1dS9A7MROBTcYsfS8DtsImMkHk9JXJ3EWQM6X2SUw4x80uGPlwj0o00Uoc6nEE3g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
"@babel/helper-skip-transparent-expression-wrappers": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-function-name": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-function-name/-/plugin-transform-function-name-7.24.7.tgz",
"integrity": "sha512-U9FcnA821YoILngSmYkW6FjyQe2TyZD5pHt4EVIhmcTkrJw/3KqcrRSxuOo5tFZJi7TE19iDyI1u+weTI7bn2w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-compilation-targets": "^7.24.7",
"@babel/helper-function-name": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/plugin-transform-json-strings": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-json-strings/-/plugin-transform-json-strings-7.24.7.tgz",
"integrity": "sha512-2yFnBGDvRuxAaE/f0vfBKvtnvvqU8tGpMHqMNpTN2oWMKIR3NqFkjaAgGwawhqK/pIN2T3XdjGPdaG0vDhOBGw==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-json-strings": "^7.8.3"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-transform-literals": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-literals/-/plugin-transform-literals-7.24.7.tgz",
"integrity": "sha512-vcwCbb4HDH+hWi8Pqenwnjy+UiklO4Kt1vfspcQYFhJdpthSnW8XvWGyDZWKNVrVbVViI/S7K9PDJZiUmP2fYQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/plugin-transform-logical-assignment-operators": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-logical-assignment-operators/-/plugin-transform-logical-assignment-operators-7.24.7.tgz",
"integrity": "sha512-4D2tpwlQ1odXmTEIFWy9ELJcZHqrStlzK/dAOWYyxX3zT0iXQB6banjgeOJQXzEc4S0E0a5A+hahxPaEFYftsw==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-logical-assignment-operators": "^7.10.4"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-transform-member-expression-literals": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-member-expression-literals/-/plugin-transform-member-expression-literals-7.24.7.tgz",
"integrity": "sha512-T/hRC1uqrzXMKLQ6UCwMT85S3EvqaBXDGf0FaMf4446Qx9vKwlghvee0+uuZcDUCZU5RuNi4781UQ7R308zzBw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-modules-amd": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-modules-amd/-/plugin-transform-modules-amd-7.24.7.tgz",
"integrity": "sha512-9+pB1qxV3vs/8Hdmz/CulFB8w2tuu6EB94JZFsjdqxQokwGa9Unap7Bo2gGBGIvPmDIVvQrom7r5m/TCDMURhg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-module-transforms": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-modules-commonjs": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-modules-commonjs/-/plugin-transform-modules-commonjs-7.24.8.tgz",
"integrity": "sha512-WHsk9H8XxRs3JXKWFiqtQebdh9b/pTk4EgueygFzYlTKAg0Ud985mSevdNjdXdFBATSKVJGQXP1tv6aGbssLKA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/helper-module-transforms": "^7.24.8",
"@babel/helper-plugin-utils": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-simple-access": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-modules-systemjs": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-modules-systemjs/-/plugin-transform-modules-systemjs-7.24.7.tgz",
"integrity": "sha512-GYQE0tW7YoaN13qFh3O1NCY4MPkUiAH3fiF7UcV/I3ajmDKEdG3l+UOcbAm4zUE3gnvUU+Eni7XrVKo9eO9auw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-hoist-variables": "^7.24.7",
"@babel/helper-module-transforms": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7",
"@babel/helper-validator-identifier": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-modules-umd": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-modules-umd/-/plugin-transform-modules-umd-7.24.7.tgz",
"integrity": "sha512-3aytQvqJ/h9z4g8AsKPLvD4Zqi2qT+L3j7XoFFu1XBlZWEl2/1kWnhmAbxpLgPrHSY0M6UA02jyTiwUVtiKR6A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-module-transforms": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-named-capturing-groups-regex": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-named-capturing-groups-regex/-/plugin-transform-named-capturing-groups-regex-7.24.7.tgz",
"integrity": "sha512-/jr7h/EWeJtk1U/uz2jlsCioHkZk1JJZVcc8oQsJ1dUlaJD83f4/6Zeh2aHt9BIFokHIsSeDfhUmju0+1GPd6g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-create-regexp-features-plugin": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0"
}
},
"node_modules/@babel/plugin-transform-new-target": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-new-target/-/plugin-transform-new-target-7.24.7.tgz",
"integrity": "sha512-RNKwfRIXg4Ls/8mMTza5oPF5RkOW8Wy/WgMAp1/F1yZ8mMbtwXW+HDoJiOsagWrAhI5f57Vncrmr9XeT4CVapA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Update npm packages
2023-05-28 09:39:34 +02:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-nullish-coalescing-operator": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-nullish-coalescing-operator/-/plugin-transform-nullish-coalescing-operator-7.24.7.tgz",
"integrity": "sha512-Ts7xQVk1OEocqzm8rHMXHlxvsfZ0cEF2yomUqpKENHWMF4zKk175Y4q8H5knJes6PgYad50uuRmt3UJuhBw8pQ==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-nullish-coalescing-operator": "^7.8.3"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-numeric-separator": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-numeric-separator/-/plugin-transform-numeric-separator-7.24.7.tgz",
"integrity": "sha512-e6q1TiVUzvH9KRvicuxdBTUj4AdKSRwzIyFFnfnezpCfP2/7Qmbb8qbU2j7GODbl4JMkblitCQjKYUaX/qkkwA==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-numeric-separator": "^7.10.4"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-object-rest-spread": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-object-rest-spread/-/plugin-transform-object-rest-spread-7.24.7.tgz",
"integrity": "sha512-4QrHAr0aXQCEFni2q4DqKLD31n2DL+RxcwnNjDFkSG0eNQ/xCavnRkfCUjsyqGC2OviNJvZOF/mQqZBw7i2C5Q==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-compilation-targets": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-object-rest-spread": "^7.8.3",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/plugin-transform-parameters": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-object-super": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-object-super/-/plugin-transform-object-super-7.24.7.tgz",
"integrity": "sha512-A/vVLwN6lBrMFmMDmPPz0jnE6ZGx7Jq7d6sT/Ev4H65RER6pZ+kczlf1DthF5N0qaPHBsI7UXiE8Zy66nmAovg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
"@babel/helper-replace-supers": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/plugin-transform-optional-catch-binding": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-optional-catch-binding/-/plugin-transform-optional-catch-binding-7.24.7.tgz",
"integrity": "sha512-uLEndKqP5BfBbC/5jTwPxLh9kqPWWgzN/f8w6UwAIirAEqiIVJWWY312X72Eub09g5KF9+Zn7+hT7sDxmhRuKA==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-optional-catch-binding": "^7.8.3"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-optional-chaining": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-optional-chaining/-/plugin-transform-optional-chaining-7.24.8.tgz",
"integrity": "sha512-5cTOLSMs9eypEy8JUVvIKOu6NgvbJMnpG62VpIHrTmROdQ+L5mDAaI40g25k5vXti55JWNX5jCkq3HZxXBQANw==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/helper-plugin-utils": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-skip-transparent-expression-wrappers": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-optional-chaining": "^7.8.3"
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-transform-parameters": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-parameters/-/plugin-transform-parameters-7.24.7.tgz",
"integrity": "sha512-yGWW5Rr+sQOhK0Ot8hjDJuxU3XLRQGflvT4lhlSY0DFvdb3TwKaY26CJzHtYllU0vT9j58hc37ndFPsqT1SrzA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Update npm packages
2023-05-28 09:39:34 +02:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-private-methods": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-private-methods/-/plugin-transform-private-methods-7.24.7.tgz",
"integrity": "sha512-COTCOkG2hn4JKGEKBADkA8WNb35TGkkRbI5iT845dB+NyqgO8Hn+ajPbSnIQznneJTa3d30scb6iz/DhH8GsJQ==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-create-class-features-plugin": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Update npm packages
2023-05-28 09:39:34 +02:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-private-property-in-object": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-private-property-in-object/-/plugin-transform-private-property-in-object-7.24.7.tgz",
"integrity": "sha512-9z76mxwnwFxMyxZWEgdgECQglF2Q7cFLm0kMf8pGwt+GSJsY0cONKj/UuO4bOH0w/uAel3ekS4ra5CEAyJRmDA==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-annotate-as-pure": "^7.24.7",
"@babel/helper-create-class-features-plugin": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-private-property-in-object": "^7.14.5"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-property-literals": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-property-literals/-/plugin-transform-property-literals-7.24.7.tgz",
"integrity": "sha512-EMi4MLQSHfd2nrCqQEWxFdha2gBCqU4ZcCng4WBGZ5CJL4bBRW0ptdqqDdeirGZcpALazVVNJqRmsO8/+oNCBA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-regenerator": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-regenerator/-/plugin-transform-regenerator-7.24.7.tgz",
"integrity": "sha512-lq3fvXPdimDrlg6LWBoqj+r/DEWgONuwjuOuQCSYgRroXDH/IdM1C0IZf59fL5cHLpjEH/O6opIRBbqv7ELnuA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
Update npm packages
2023-08-19 09:08:11 +02:00
"regenerator-transform": "^0.15.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-reserved-words": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-reserved-words/-/plugin-transform-reserved-words-7.24.7.tgz",
"integrity": "sha512-0DUq0pHcPKbjFZCfTss/pGkYMfy3vFWydkUBd9r0GHpIyfs2eCDENvqadMycRS9wZCXR41wucAfJHJmwA0UmoQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-shorthand-properties": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-shorthand-properties/-/plugin-transform-shorthand-properties-7.24.7.tgz",
"integrity": "sha512-KsDsevZMDsigzbA09+vacnLpmPH4aWjcZjXdyFKGzpplxhbeB4wYtury3vglQkg6KM/xEPKt73eCjPPf1PgXBA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-spread": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-spread/-/plugin-transform-spread-7.24.7.tgz",
"integrity": "sha512-x96oO0I09dgMDxJaANcRyD4ellXFLLiWhuwDxKZX5g2rWP1bTPkBSwCYv96VDXVT1bD9aPj8tppr5ITIh8hBng==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7",
"@babel/helper-skip-transparent-expression-wrappers": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-sticky-regex": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-sticky-regex/-/plugin-transform-sticky-regex-7.24.7.tgz",
"integrity": "sha512-kHPSIJc9v24zEml5geKg9Mjx5ULpfncj0wRpYtxbvKyTtHCYDkVE3aHQ03FrpEo4gEe2vrJJS1Y9CJTaThA52g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-template-literals": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-template-literals/-/plugin-transform-template-literals-7.24.7.tgz",
"integrity": "sha512-AfDTQmClklHCOLxtGoP7HkeMw56k1/bTQjwsfhL6pppo/M4TOBSq+jjBUBLmV/4oeFg4GWMavIl44ZeCtmmZTw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-typeof-symbol": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-typeof-symbol/-/plugin-transform-typeof-symbol-7.24.8.tgz",
"integrity": "sha512-adNTUpDCVnmAE58VEqKlAA6ZBlNkMnWD0ZcW76lyNFN3MJniyGFZfNwERVk8Ap56MCnXztmDr19T4mPTztcuaw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/helper-plugin-utils": "^7.24.8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/plugin-transform-unicode-escapes": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-unicode-escapes/-/plugin-transform-unicode-escapes-7.24.7.tgz",
"integrity": "sha512-U3ap1gm5+4edc2Q/P+9VrBNhGkfnf+8ZqppY71Bo/pzZmXhhLdqgaUl6cuB07O1+AQJtCLfaOmswiNbSQ9ivhw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/plugin-transform-unicode-property-regex": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-unicode-property-regex/-/plugin-transform-unicode-property-regex-7.24.7.tgz",
"integrity": "sha512-uH2O4OV5M9FZYQrwc7NdVmMxQJOCCzFeYudlZSzUAHRFeOujQefa92E74TQDVskNHCzOXoigEuoyzHDhaEaK5w==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-create-regexp-features-plugin": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Update npm packages
2023-05-28 09:39:34 +02:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/plugin-transform-unicode-regex": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-unicode-regex/-/plugin-transform-unicode-regex-7.24.7.tgz",
"integrity": "sha512-hlQ96MBZSAXUq7ltkjtu3FJCCSMx/j629ns3hA3pXnBXjanNP0LHi+JpPeA81zaWgVK1VGH95Xuy7u0RyQ8kMg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-create-regexp-features-plugin": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/@babel/plugin-transform-unicode-sets-regex": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/plugin-transform-unicode-sets-regex/-/plugin-transform-unicode-sets-regex-7.24.7.tgz",
"integrity": "sha512-2G8aAvF4wy1w/AGZkemprdGMRg5o6zPNhbHVImRz3lss55TYCBd6xStN19rt8XJHq20sqV0JbyWjOWwQRwV/wg==",
Update npm packages
2023-05-28 09:39:34 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-05-28 09:39:34 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-create-regexp-features-plugin": "^7.24.7",
"@babel/helper-plugin-utils": "^7.24.7"
Update npm packages
2023-05-28 09:39:34 +02:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/preset-env": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/preset-env/-/preset-env-7.24.8.tgz",
"integrity": "sha512-vObvMZB6hNWuDxhSaEPTKCwcqkAIuDtE+bQGn4XMXne1DSLzFVY8Vmj1bm+mUQXYNN8NmaQEO+r8MMbzPr1jBQ==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "MIT",
"dependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/compat-data": "^7.24.8",
"@babel/helper-compilation-targets": "^7.24.8",
"@babel/helper-plugin-utils": "^7.24.8",
"@babel/helper-validator-option": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/plugin-bugfix-firefox-class-in-computed-class-key": "^7.24.7",
"@babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression": "^7.24.7",
"@babel/plugin-bugfix-v8-spread-parameters-in-optional-chaining": "^7.24.7",
"@babel/plugin-bugfix-v8-static-class-fields-redefine-readonly": "^7.24.7",
Update npm packages
2023-06-11 11:30:39 +02:00
"@babel/plugin-proposal-private-property-in-object": "7.21.0-placeholder-for-preset-env.2",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"@babel/plugin-syntax-async-generators": "^7.8.4",
"@babel/plugin-syntax-class-properties": "^7.12.13",
"@babel/plugin-syntax-class-static-block": "^7.14.5",
"@babel/plugin-syntax-dynamic-import": "^7.8.3",
"@babel/plugin-syntax-export-namespace-from": "^7.8.3",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/plugin-syntax-import-assertions": "^7.24.7",
"@babel/plugin-syntax-import-attributes": "^7.24.7",
Update npm packages
2023-05-14 10:12:06 +02:00
"@babel/plugin-syntax-import-meta": "^7.10.4",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"@babel/plugin-syntax-json-strings": "^7.8.3",
"@babel/plugin-syntax-logical-assignment-operators": "^7.10.4",
"@babel/plugin-syntax-nullish-coalescing-operator": "^7.8.3",
"@babel/plugin-syntax-numeric-separator": "^7.10.4",
"@babel/plugin-syntax-object-rest-spread": "^7.8.3",
"@babel/plugin-syntax-optional-catch-binding": "^7.8.3",
"@babel/plugin-syntax-optional-chaining": "^7.8.3",
"@babel/plugin-syntax-private-property-in-object": "^7.14.5",
"@babel/plugin-syntax-top-level-await": "^7.14.5",
Update npm packages
2023-05-28 09:39:34 +02:00
"@babel/plugin-syntax-unicode-sets-regex": "^7.18.6",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/plugin-transform-arrow-functions": "^7.24.7",
"@babel/plugin-transform-async-generator-functions": "^7.24.7",
"@babel/plugin-transform-async-to-generator": "^7.24.7",
"@babel/plugin-transform-block-scoped-functions": "^7.24.7",
"@babel/plugin-transform-block-scoping": "^7.24.7",
"@babel/plugin-transform-class-properties": "^7.24.7",
"@babel/plugin-transform-class-static-block": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/plugin-transform-classes": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/plugin-transform-computed-properties": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/plugin-transform-destructuring": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/plugin-transform-dotall-regex": "^7.24.7",
"@babel/plugin-transform-duplicate-keys": "^7.24.7",
"@babel/plugin-transform-dynamic-import": "^7.24.7",
"@babel/plugin-transform-exponentiation-operator": "^7.24.7",
"@babel/plugin-transform-export-namespace-from": "^7.24.7",
"@babel/plugin-transform-for-of": "^7.24.7",
"@babel/plugin-transform-function-name": "^7.24.7",
"@babel/plugin-transform-json-strings": "^7.24.7",
"@babel/plugin-transform-literals": "^7.24.7",
"@babel/plugin-transform-logical-assignment-operators": "^7.24.7",
"@babel/plugin-transform-member-expression-literals": "^7.24.7",
"@babel/plugin-transform-modules-amd": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/plugin-transform-modules-commonjs": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/plugin-transform-modules-systemjs": "^7.24.7",
"@babel/plugin-transform-modules-umd": "^7.24.7",
"@babel/plugin-transform-named-capturing-groups-regex": "^7.24.7",
"@babel/plugin-transform-new-target": "^7.24.7",
"@babel/plugin-transform-nullish-coalescing-operator": "^7.24.7",
"@babel/plugin-transform-numeric-separator": "^7.24.7",
"@babel/plugin-transform-object-rest-spread": "^7.24.7",
"@babel/plugin-transform-object-super": "^7.24.7",
"@babel/plugin-transform-optional-catch-binding": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/plugin-transform-optional-chaining": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/plugin-transform-parameters": "^7.24.7",
"@babel/plugin-transform-private-methods": "^7.24.7",
"@babel/plugin-transform-private-property-in-object": "^7.24.7",
"@babel/plugin-transform-property-literals": "^7.24.7",
"@babel/plugin-transform-regenerator": "^7.24.7",
"@babel/plugin-transform-reserved-words": "^7.24.7",
"@babel/plugin-transform-shorthand-properties": "^7.24.7",
"@babel/plugin-transform-spread": "^7.24.7",
"@babel/plugin-transform-sticky-regex": "^7.24.7",
"@babel/plugin-transform-template-literals": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/plugin-transform-typeof-symbol": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/plugin-transform-unicode-escapes": "^7.24.7",
"@babel/plugin-transform-unicode-property-regex": "^7.24.7",
"@babel/plugin-transform-unicode-regex": "^7.24.7",
"@babel/plugin-transform-unicode-sets-regex": "^7.24.7",
Update npm packages
2023-08-19 09:08:11 +02:00
"@babel/preset-modules": "0.1.6-no-external-plugins",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"babel-plugin-polyfill-corejs2": "^0.4.10",
"babel-plugin-polyfill-corejs3": "^0.10.4",
"babel-plugin-polyfill-regenerator": "^0.6.1",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"core-js-compat": "^3.37.1",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"semver": "^6.3.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
},
"peerDependencies": {
"@babel/core": "^7.0.0-0"
}
},
"node_modules/@babel/preset-env/node_modules/semver": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"version": "6.3.1",
"resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz",
"integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"bin": {
"semver": "bin/semver.js"
}
},
"node_modules/@babel/preset-modules": {
Update npm packages
2023-08-19 09:08:11 +02:00
"version": "0.1.6-no-external-plugins",
"resolved": "https://registry.npmjs.org/@babel/preset-modules/-/preset-modules-0.1.6-no-external-plugins.tgz",
"integrity": "sha512-HrcgcIESLm9aIR842yhJ5RWan/gebQUJ6E/E5+rf0y9o6oj7w0Br+sWuL6kEQ/o/AdfvR1Je9jG18/gnpwjEyA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"@babel/helper-plugin-utils": "^7.0.0",
"@babel/types": "^7.4.4",
"esutils": "^2.0.2"
},
"peerDependencies": {
Update npm packages
2023-08-19 09:08:11 +02:00
"@babel/core": "^7.0.0-0 || ^8.0.0-0 <8.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update npm packages
2023-04-15 22:08:58 +02:00
"node_modules/@babel/regjsgen": {
"version": "0.8.0",
"resolved": "https://registry.npmjs.org/@babel/regjsgen/-/regjsgen-0.8.0.tgz",
"integrity": "sha512-x/rqGMdzj+fWZvCOYForTghzbtqPDZ5gPwaoNGHdgDfF2QA/XZbCBp4Moo5scrkAMPhB7z26XM/AaHuIJdgauA==",
"dev": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@babel/runtime": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/runtime/-/runtime-7.24.8.tgz",
"integrity": "sha512-5F7SDGs1T72ZczbRwbGO9lQi0NLjQxzl6i4lJxLxfW9U5UluCSyEJeniWvnhl3/euNiqQVbo8zruhsDfid0esA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update npm packages
2023-08-19 09:08:11 +02:00
"regenerator-runtime": "^0.14.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/runtime/node_modules/regenerator-runtime": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "0.14.1",
"resolved": "https://registry.npmjs.org/regenerator-runtime/-/regenerator-runtime-0.14.1.tgz",
"integrity": "sha512-dYnhHh0nJoMfnkZs6GmmhFknAGRrLznOu5nc9ML+EJxGvrx6H7teuevqVqCuPcPK//3eDrrjQhehXVx9cnkGdw==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "MIT"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"node_modules/@babel/template": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "7.24.7",
"resolved": "https://registry.npmjs.org/@babel/template/-/template-7.24.7.tgz",
"integrity": "sha512-jYqfPrU9JTF0PmPy1tLYHW4Mp4KlgxJD9l2nP9fD6yT/ICi554DmrWBAEYpIelzjHf1msDP3PxJIRt/nFNfBig==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/code-frame": "^7.24.7",
"@babel/parser": "^7.24.7",
"@babel/types": "^7.24.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/traverse": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/traverse/-/traverse-7.24.8.tgz",
"integrity": "sha512-t0P1xxAPzEDcEPmjprAQq19NWum4K0EQPjMwZQZbHt+GiZqvjCHjj755Weq1YRPVzBI+3zSfvScfpnuIecVFJQ==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "MIT",
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/code-frame": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/generator": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-environment-visitor": "^7.24.7",
"@babel/helper-function-name": "^7.24.7",
"@babel/helper-hoist-variables": "^7.24.7",
"@babel/helper-split-export-declaration": "^7.24.7",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/parser": "^7.24.8",
"@babel/types": "^7.24.8",
Update npm packages
2023-12-23 12:29:51 +01:00
"debug": "^4.3.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"globals": "^11.1.0"
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/traverse/node_modules/debug": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "4.3.5",
"resolved": "https://registry.npmjs.org/debug/-/debug-4.3.5.tgz",
"integrity": "sha512-pt0bNEmneDIvdL1Xsd9oDQ/wrQRkXDT4AUWlNZNPKvW5x/jyO9VFXkJUP07vQ2upmw5PlaITaPKc31jK13V+jg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"ms": "2.1.2"
},
"engines": {
"node": ">=6.0"
},
"peerDependenciesMeta": {
"supports-color": {
"optional": true
}
}
},
"node_modules/@babel/traverse/node_modules/globals": {
"version": "11.12.0",
"resolved": "https://registry.npmjs.org/globals/-/globals-11.12.0.tgz",
"integrity": "sha512-WOBp/EEGUiIsJSp7wcv/y6MO+lV9UoncWqxuFfm8eBwzWNgyfBd6Gz+IeKQ9jCmyhoH99g15M3T+QaVHFjizVA==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=4"
}
},
"node_modules/@babel/types": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "7.24.8",
"resolved": "https://registry.npmjs.org/@babel/types/-/types-7.24.8.tgz",
"integrity": "sha512-SkSBEHwwJRU52QEVZBmMBnE5Ux2/6WU1grdYyOhpbCNxbmJrDuDCphBzKZSO3taf0zztp+qkWlymE5tVL5l0TA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@babel/helper-string-parser": "^7.24.8",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"@babel/helper-validator-identifier": "^7.24.7",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"to-fast-properties": "^2.0.0"
},
"engines": {
"node": ">=6.9.0"
}
},
"node_modules/@babel/types/node_modules/to-fast-properties": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/to-fast-properties/-/to-fast-properties-2.0.0.tgz",
"integrity": "sha1-3F5pjL0HkmW8c+A3doGk5Og/YW4=",
"dev": true,
"engines": {
"node": ">=4"
}
},
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"node_modules/@csstools/css-parser-algorithms": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "2.7.1",
"resolved": "https://registry.npmjs.org/@csstools/css-parser-algorithms/-/css-parser-algorithms-2.7.1.tgz",
"integrity": "sha512-2SJS42gxmACHgikc1WGesXLIT8d/q2l0UFM7TaEeIzdFCE/FPMtTiizcPGGJtlPo2xuQzY09OhrLTzRxqJqwGw==",
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"dev": true,
Update npm packages
2023-06-11 11:30:39 +02:00
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/csstools"
},
{
"type": "opencollective",
"url": "https://opencollective.com/csstools"
}
],
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"engines": {
"node": "^14 || ^16 || >=18"
},
"peerDependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@csstools/css-tokenizer": "^2.4.1"
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
}
},
"node_modules/@csstools/css-tokenizer": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "2.4.1",
"resolved": "https://registry.npmjs.org/@csstools/css-tokenizer/-/css-tokenizer-2.4.1.tgz",
"integrity": "sha512-eQ9DIktFJBhGjioABJRtUucoWR2mwllurfnM8LuNGAqX3ViZXaUchqk+1s7jjtkFiT9ySdACsFEA3etErkALUg==",
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"dev": true,
Update npm packages
2023-08-19 09:08:11 +02:00
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/csstools"
},
{
"type": "opencollective",
"url": "https://opencollective.com/csstools"
}
],
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"engines": {
"node": "^14 || ^16 || >=18"
}
},
"node_modules/@csstools/media-query-list-parser": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "2.1.13",
"resolved": "https://registry.npmjs.org/@csstools/media-query-list-parser/-/media-query-list-parser-2.1.13.tgz",
"integrity": "sha512-XaHr+16KRU9Gf8XLi3q8kDlI18d5vzKSKCY510Vrtc9iNR0NJzbY9hhTmwhzYZj/ZwGL4VmB3TA9hJW0Um2qFA==",
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"dev": true,
Update npm packages
2023-06-11 11:30:39 +02:00
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/csstools"
},
{
"type": "opencollective",
"url": "https://opencollective.com/csstools"
}
],
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"engines": {
"node": "^14 || ^16 || >=18"
},
"peerDependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@csstools/css-parser-algorithms": "^2.7.1",
"@csstools/css-tokenizer": "^2.4.1"
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
}
},
Update npm packages
2024-03-17 13:50:21 +01:00
"node_modules/@csstools/selector-resolve-nested": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/@csstools/selector-resolve-nested/-/selector-resolve-nested-1.1.0.tgz",
"integrity": "sha512-uWvSaeRcHyeNenKg8tp17EVDRkpflmdyvbE0DHo6D/GdBb6PDnCYYU6gRpXhtICMGMcahQmj2zGxwFM/WC8hCg==",
"dev": true,
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/csstools"
},
{
"type": "opencollective",
"url": "https://opencollective.com/csstools"
}
],
"engines": {
"node": "^14 || ^16 || >=18"
},
"peerDependencies": {
"postcss-selector-parser": "^6.0.13"
}
},
Update npm packages
2022-06-12 14:02:31 +02:00
"node_modules/@csstools/selector-specificity": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"version": "3.1.1",
"resolved": "https://registry.npmjs.org/@csstools/selector-specificity/-/selector-specificity-3.1.1.tgz",
"integrity": "sha512-a7cxGcJ2wIlMFLlh8z2ONm+715QkPHiyJcxwQlKOz/03GPw1COpfhcmC9wm4xlZfp//jWHNNMwzjtqHXVWU9KA==",
Update npm packages
2022-06-12 14:02:31 +02:00
"dev": true,
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/csstools"
},
{
"type": "opencollective",
"url": "https://opencollective.com/csstools"
}
],
Update npm packages
2022-06-12 14:02:31 +02:00
"engines": {
Update npm packages
2023-02-11 10:24:22 +01:00
"node": "^14 || ^16 || >=18"
Update npm packages
2022-06-12 14:02:31 +02:00
},
"peerDependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"postcss-selector-parser": "^6.0.13"
Update npm packages
2022-06-12 14:02:31 +02:00
}
},
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"node_modules/@dual-bundle/import-meta-resolve": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"version": "4.1.0",
"resolved": "https://registry.npmjs.org/@dual-bundle/import-meta-resolve/-/import-meta-resolve-4.1.0.tgz",
"integrity": "sha512-+nxncfwHM5SgAtrVzgpzJOI1ol0PkumhVo469KCf9lUi21IGcY90G98VuHm9VRrUypmAzawAHO9bs6hqeADaVg==",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"funding": {
"type": "github",
"url": "https://github.com/sponsors/wooorm"
}
},
Update npm packages
2022-12-25 12:26:23 +01:00
"node_modules/@eslint-community/eslint-utils": {
Update npm packages
2023-05-14 10:12:06 +02:00
"version": "4.4.0",
"resolved": "https://registry.npmjs.org/@eslint-community/eslint-utils/-/eslint-utils-4.4.0.tgz",
"integrity": "sha512-1/sA4dwrzBAyeUoQ6oxahHKmrZvsnLCg4RfxW3ZFGGmQkSNQPFNLV9CUEFQP1x9EYXHTo5p6xdhZM1Ne9p/AfA==",
Update npm packages
2022-12-25 12:26:23 +01:00
"dev": true,
"dependencies": {
"eslint-visitor-keys": "^3.3.0"
},
"engines": {
"node": "^12.22.0 || ^14.17.0 || >=16.0.0"
},
"peerDependencies": {
Update npm packages
2023-03-12 10:27:52 +01:00
"eslint": "^6.0.0 || ^7.0.0 || >=8.0.0"
Update npm packages
2022-12-25 12:26:23 +01:00
}
},
Update npm packages
2023-03-12 10:27:52 +01:00
"node_modules/@eslint-community/regexpp": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "4.6.2",
"resolved": "https://registry.npmjs.org/@eslint-community/regexpp/-/regexpp-4.6.2.tgz",
"integrity": "sha512-pPTNuaAG3QMH+buKyBIGJs3g/S5y0caxw0ygM3YyE6yJFySwiGGSzA+mM3KJ8QQvzeLh3blwgSonkFjgQdxzMw==",
Update npm packages
2023-03-12 10:27:52 +01:00
"dev": true,
"engines": {
"node": "^12.0.0 || ^14.0.0 || >=16.0.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@eslint/eslintrc": {
Update npm packages
2023-12-23 12:29:51 +01:00
"version": "2.1.4",
"resolved": "https://registry.npmjs.org/@eslint/eslintrc/-/eslintrc-2.1.4.tgz",
"integrity": "sha512-269Z39MS6wVJtsoUl10L60WdkhJVdPG24Q4eZTH3nnF6lpvSShEK3wQjDX9JRWAUPvPh7COouPpU9IrqaZFvtQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"ajv": "^6.12.4",
"debug": "^4.3.2",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"espree": "^9.6.0",
Update npm packages
2022-12-25 12:26:23 +01:00
"globals": "^13.19.0",
Update npm packages Note that the Prettier update made it possible to move a couple of comments after `default:`-cases back to their original/intended positions, please see https://prettier.io/blog/2022/03/16/2.6.0.html
2022-03-20 10:36:11 +01:00
"ignore": "^5.2.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"import-fresh": "^3.2.1",
"js-yaml": "^4.1.0",
Update npm packages
2022-05-15 09:02:57 +02:00
"minimatch": "^3.1.2",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"strip-json-comments": "^3.1.1"
},
"engines": {
"node": "^12.22.0 || ^14.17.0 || >=16.0.0"
Update npm packages
2022-09-04 09:57:59 +02:00
},
"funding": {
"url": "https://opencollective.com/eslint"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/@eslint/eslintrc/node_modules/argparse": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
"integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
"dev": true
},
Update `globals` to version 14.0.0 This is a major version bump, but the breaking changes don't affect us; please see https://github.com/sindresorhus/globals/releases/tag/v14.0.0.
2024-02-10 18:08:25 +01:00
"node_modules/@eslint/eslintrc/node_modules/globals": {
"version": "13.24.0",
"resolved": "https://registry.npmjs.org/globals/-/globals-13.24.0.tgz",
"integrity": "sha512-AhO5QUcj8llrbG09iWhPU2B204J1xnPeL8kQmVorSsy+Sjj1sk8gIyh6cUocGmH4L0UuhAJy+hJMRA4mgA4mFQ==",
"dev": true,
"dependencies": {
"type-fest": "^0.20.2"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@eslint/eslintrc/node_modules/js-yaml": {
"version": "4.1.0",
"resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz",
"integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==",
"dev": true,
"dependencies": {
"argparse": "^2.0.1"
},
"bin": {
"js-yaml": "bin/js-yaml.js"
}
},
Update `globals` to version 14.0.0 This is a major version bump, but the breaking changes don't affect us; please see https://github.com/sindresorhus/globals/releases/tag/v14.0.0.
2024-02-10 18:08:25 +01:00
"node_modules/@eslint/eslintrc/node_modules/type-fest": {
"version": "0.20.2",
"resolved": "https://registry.npmjs.org/type-fest/-/type-fest-0.20.2.tgz",
"integrity": "sha512-Ne+eE4r0/iWnpAxD852z3A+N0Bt5RN//NjJwRd2VFHEmrywxf5vsZlh4R6lixl6B+wz/8d+maTSAkN1FIkI3LQ==",
"dev": true,
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Update npm packages
2023-03-12 10:27:52 +01:00
"node_modules/@eslint/js": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "8.57.0",
"resolved": "https://registry.npmjs.org/@eslint/js/-/js-8.57.0.tgz",
"integrity": "sha512-Ys+3g2TaW7gADOJzPt83SJtCDhMjndcDMFVQ/Tj9iA1BfJzFKD9mAUXT3OenpuPHbI6P/myECxRJrofUsDx/5g==",
Update npm packages
2023-03-12 10:27:52 +01:00
"dev": true,
"engines": {
"node": "^12.22.0 || ^14.17.0 || >=16.0.0"
}
},
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 16:23:17 +02:00
"node_modules/@fluent/bundle": {
"version": "0.18.0",
"resolved": "https://registry.npmjs.org/@fluent/bundle/-/bundle-0.18.0.tgz",
"integrity": "sha512-8Wfwu9q8F9g2FNnv82g6Ch/E1AW1wwljsUOolH5NEtdJdv0sZTuWvfCM7c3teB9dzNaJA8rn4khpidpozHWYEA==",
"dev": true,
"engines": {
"node": ">=14.0.0",
"npm": ">=7.0.0"
}
},
"node_modules/@fluent/dom": {
Remove the `requestAnimationFrame` work-around in `L10n.prototype.destroy` (PR 18313 follow-up) With `@fluent/dom 0.10.0` just published this work-around is no longer necessary.
2024-06-25 17:23:19 +02:00
"version": "0.10.0",
"resolved": "https://registry.npmjs.org/@fluent/dom/-/dom-0.10.0.tgz",
"integrity": "sha512-31a+GJRg6Xhpw9IQ8yNiHhegd10g1DvC30TMSO52bFpjJVJqfQHTuLKFSORNR5xI1oyP4RU4lGLho9+HaC/pVQ==",
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 16:23:17 +02:00
"dev": true,
Remove the `requestAnimationFrame` work-around in `L10n.prototype.destroy` (PR 18313 follow-up) With `@fluent/dom 0.10.0` just published this work-around is no longer necessary.
2024-06-25 17:23:19 +02:00
"license": "Apache-2.0",
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 16:23:17 +02:00
"dependencies": {
"cached-iterable": "^0.3"
},
"engines": {
Remove the `requestAnimationFrame` work-around in `L10n.prototype.destroy` (PR 18313 follow-up) With `@fluent/dom 0.10.0` just published this work-around is no longer necessary.
2024-06-25 17:23:19 +02:00
"node": ">=18.0.0",
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 16:23:17 +02:00
"npm": ">=7.0.0"
}
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/@gulpjs/messages": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/@gulpjs/messages/-/messages-1.1.0.tgz",
"integrity": "sha512-Ys9sazDatyTgZVb4xPlDufLweJ/Os2uHWOv+Caxvy2O85JcnT4M3vc73bi8pdLWlv3fdWQz3pdI9tVwo8rQQSg==",
"dev": true,
"engines": {
"node": ">=10.13.0"
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/@gulpjs/to-absolute-glob": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/@gulpjs/to-absolute-glob/-/to-absolute-glob-4.0.0.tgz",
"integrity": "sha512-kjotm7XJrJ6v+7knhPaRgaT6q8F8K2jiafwYdNHLzmV0uGLuZY43FK6smNSHUPrhq5kX2slCUy+RGG/xGqmIKA==",
"dev": true,
"license": "MIT",
"dependencies": {
"is-negated-glob": "^1.0.0"
},
"engines": {
"node": ">=10.13.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@humanwhocodes/config-array": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "0.11.14",
"resolved": "https://registry.npmjs.org/@humanwhocodes/config-array/-/config-array-0.11.14.tgz",
"integrity": "sha512-3T8LkOmg45BV5FICb15QQMsyUSWrQ8AygVfC7ZG32zOalnqrilm018ZVCw0eapXux8FtA33q8PSRSstjee3jSg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2024-03-17 13:50:21 +01:00
"@humanwhocodes/object-schema": "^2.0.2",
"debug": "^4.3.1",
Update npm packages
2022-10-29 10:17:36 +02:00
"minimatch": "^3.0.5"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=10.10.0"
}
},
Update npm packages
2022-09-04 09:57:59 +02:00
"node_modules/@humanwhocodes/module-importer": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/@humanwhocodes/module-importer/-/module-importer-1.0.1.tgz",
"integrity": "sha512-bxveV4V8v5Yb4ncFTT3rPSgZBOpCkjfK0y4oVVVJwIuDVBRMDXrPyXRL988i5ap9m9bnyEEjWfm5WkBmtffLfA==",
"dev": true,
"engines": {
"node": ">=12.22"
},
"funding": {
"type": "github",
"url": "https://github.com/sponsors/nzakas"
}
},
Update npm packages
2024-03-17 13:50:21 +01:00
"node_modules/@humanwhocodes/object-schema": {
"version": "2.0.2",
"resolved": "https://registry.npmjs.org/@humanwhocodes/object-schema/-/object-schema-2.0.2.tgz",
"integrity": "sha512-6EwiSjwWYP7pTckG6I5eyFANjPhmPjUX9JRLUSfNPC7FX7zK9gyZAfUEaECL6ALTpGX5AjnBq3C9XmVWPitNpw==",
"dev": true
},
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node_modules/@isaacs/cliui": {
"version": "8.0.2",
"resolved": "https://registry.npmjs.org/@isaacs/cliui/-/cliui-8.0.2.tgz",
"integrity": "sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA==",
"dev": true,
"dependencies": {
"string-width": "^5.1.2",
"string-width-cjs": "npm:string-width@^4.2.0",
"strip-ansi": "^7.0.1",
"strip-ansi-cjs": "npm:strip-ansi@^6.0.1",
"wrap-ansi": "^8.1.0",
"wrap-ansi-cjs": "npm:wrap-ansi@^7.0.0"
},
"engines": {
"node": ">=12"
}
},
"node_modules/@isaacs/cliui/node_modules/ansi-regex": {
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.0.1.tgz",
"integrity": "sha512-n5M855fKb2SsfMIiFFoVrABHJC8QtHwVx+mHWP3QcEqBHYienj5dHSgjbxtC0WEZXYt4wcD6zrQElDPhFuZgfA==",
"dev": true,
"engines": {
"node": ">=12"
},
"funding": {
"url": "https://github.com/chalk/ansi-regex?sponsor=1"
}
},
"node_modules/@isaacs/cliui/node_modules/ansi-styles": {
"version": "6.2.1",
"resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-6.2.1.tgz",
"integrity": "sha512-bN798gFfQX+viw3R7yrGWRqnrN2oRkEkUjjl4JNn4E8GxxbjtG3FbrEIIY3l8/hrwUwIeCZvi4QuOTP4MErVug==",
"dev": true,
"engines": {
"node": ">=12"
},
"funding": {
"url": "https://github.com/chalk/ansi-styles?sponsor=1"
}
},
"node_modules/@isaacs/cliui/node_modules/emoji-regex": {
"version": "9.2.2",
"resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-9.2.2.tgz",
"integrity": "sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==",
"dev": true
},
"node_modules/@isaacs/cliui/node_modules/string-width": {
"version": "5.1.2",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-5.1.2.tgz",
"integrity": "sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==",
"dev": true,
"dependencies": {
"eastasianwidth": "^0.2.0",
"emoji-regex": "^9.2.2",
"strip-ansi": "^7.0.1"
},
"engines": {
"node": ">=12"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/@isaacs/cliui/node_modules/strip-ansi": {
"version": "7.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.0.1.tgz",
"integrity": "sha512-cXNxvT8dFNRVfhVME3JAe98mkXDYN2O1l7jmcwMnOslDeESg1rF/OZMtK0nRAhiari1unG5cD4jG3rapUAkLbw==",
"dev": true,
"dependencies": {
"ansi-regex": "^6.0.1"
},
"engines": {
"node": ">=12"
},
"funding": {
"url": "https://github.com/chalk/strip-ansi?sponsor=1"
}
},
"node_modules/@isaacs/cliui/node_modules/wrap-ansi": {
"version": "8.1.0",
"resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-8.1.0.tgz",
"integrity": "sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ==",
"dev": true,
"dependencies": {
"ansi-styles": "^6.1.0",
"string-width": "^5.0.1",
"strip-ansi": "^7.0.1"
},
"engines": {
"node": ">=12"
},
"funding": {
"url": "https://github.com/chalk/wrap-ansi?sponsor=1"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/@istanbuljs/schema": {
"version": "0.1.3",
"resolved": "https://registry.npmjs.org/@istanbuljs/schema/-/schema-0.1.3.tgz",
"integrity": "sha512-ZXRY4jNvVgSVQ8DL3LTcakaAtXwTVUxE81hslsyD2AtoXW/wVob10HkOJ1X/pAlcI7D+2YoZKg5do8G/w6RYgA==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/@jazzer.js/bug-detectors": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/@jazzer.js/bug-detectors/-/bug-detectors-2.1.0.tgz",
"integrity": "sha512-rFERKoSkLNZq52rRCXQKRqLX9Bfkb2+tzMrI/tDQ27//HwfdaJUej4MPKXg3YxFSGAEtshNNSXAn2liJmyLWpQ==",
"dev": true,
"dependencies": {
"@jazzer.js/core": "2.1.0",
"@jazzer.js/hooking": "2.1.0"
},
"engines": {
"node": ">= 14.0.0",
"npm": ">= 7.0.0"
}
},
"node_modules/@jazzer.js/core": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/@jazzer.js/core/-/core-2.1.0.tgz",
"integrity": "sha512-9uTuKlZ0WyC8evq++46TYg0SFszGx7X4/Y8nVsFmIg9sc0ceO9fmE1qg8KOafkzM9DvSdv+JL2UYWxnmgE1CJQ==",
"dev": true,
"dependencies": {
"@jazzer.js/bug-detectors": "2.1.0",
"@jazzer.js/fuzzer": "2.1.0",
"@jazzer.js/hooking": "2.1.0",
"@jazzer.js/instrumentor": "2.1.0",
"istanbul-lib-coverage": "^3.2.0",
"istanbul-lib-report": "^3.0.1",
"istanbul-reports": "^3.1.6",
"tmp": "^0.2.1",
"yargs": "^17.7.2"
},
"bin": {
"jazzer": "dist/cli.js"
},
"engines": {
"node": ">= 14.0.0",
"npm": ">= 7.0.0"
}
},
"node_modules/@jazzer.js/fuzzer": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/@jazzer.js/fuzzer/-/fuzzer-2.1.0.tgz",
"integrity": "sha512-WroUAGH1+AFoI+5kRGOjvh9+1GsYEmCinvEt9yF0E0pBTeadssCG6Y8adeYh6W0rum2LjPsjVfLEWMunRLt/Ew==",
"dev": true,
"hasInstallScript": true,
"dependencies": {
"bindings": "^1.5.0",
"cmake-js": "^7.2.1",
"node-addon-api": "^7.0.0",
"prebuild-install": "^7.1.1"
},
"engines": {
"node": ">= 14.0.0",
"npm": ">= 7.0.0"
}
},
"node_modules/@jazzer.js/hooking": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/@jazzer.js/hooking/-/hooking-2.1.0.tgz",
"integrity": "sha512-caNQslD27mxkYfi7woVEN98rbPL41Ezn/pGkMB/ghcBWcG0jCJDqacRJX4Gv8ypfIhemDJEocL26Ld2XSx07Pw==",
"dev": true,
"dependencies": {
"@babel/core": "^7.23.2"
},
"engines": {
"node": ">= 14.0.0",
"npm": ">= 7.0.0"
}
},
"node_modules/@jazzer.js/instrumentor": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/@jazzer.js/instrumentor/-/instrumentor-2.1.0.tgz",
"integrity": "sha512-ewvx2DKczcwusO5XlRYaMO757cFDKY+mEbS2g5k81Razq3AA/uRVU1/Ei/1FZeg9tKCuaTq9Gwl+9bdA9ER8Og==",
"dev": true,
"dependencies": {
"@babel/core": "^7.23.2",
"@babel/generator": "^7.23.0",
"@jazzer.js/fuzzer": "2.1.0",
"@jazzer.js/hooking": "2.1.0",
"istanbul-lib-hook": "^3.0.0",
"istanbul-lib-instrument": "^6.0.1",
"proper-lockfile": "^4.1.2",
"source-map-support": "^0.5.21"
},
"engines": {
"node": ">= 14.0.0",
"npm": ">= 7.0.0"
}
},
Update dependencies to the most recent versions There are two notable changes here: - `dommatrix` is a major version upgrade, but looking through the commit history of their `package.json` file at https://github.com/thednp/dommatrix/commits/master/package.json (due to the lack of a changelog) I couldn't find any breaking changes. - `es-module-shims` is a regular update, but it was previously pinned for causing intermittent breakage when running the unit tests in a browser manually. Fortunately this cannot be reproduced anymore with the most recent version, so we can also put the caret back now.
2022-04-30 19:56:10 +02:00
"node_modules/@jridgewell/gen-mapping": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "0.3.5",
"resolved": "https://registry.npmjs.org/@jridgewell/gen-mapping/-/gen-mapping-0.3.5.tgz",
"integrity": "sha512-IzL8ZoEDIBRWEzlCcRhOaCupYyN5gdIK+Q6fbFdPDg6HqX6jpkItn7DFIpW9LQzXG6Df9sA7+OKnq0qlz/GaQg==",
Update dependencies to the most recent versions There are two notable changes here: - `dommatrix` is a major version upgrade, but looking through the commit history of their `package.json` file at https://github.com/thednp/dommatrix/commits/master/package.json (due to the lack of a changelog) I couldn't find any breaking changes. - `es-module-shims` is a regular update, but it was previously pinned for causing intermittent breakage when running the unit tests in a browser manually. Fortunately this cannot be reproduced anymore with the most recent version, so we can also put the caret back now.
2022-04-30 19:56:10 +02:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@jridgewell/set-array": "^1.2.1",
Update npm packages
2022-05-29 09:28:39 +02:00
"@jridgewell/sourcemap-codec": "^1.4.10",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@jridgewell/trace-mapping": "^0.3.24"
Update dependencies to the most recent versions There are two notable changes here: - `dommatrix` is a major version upgrade, but looking through the commit history of their `package.json` file at https://github.com/thednp/dommatrix/commits/master/package.json (due to the lack of a changelog) I couldn't find any breaking changes. - `es-module-shims` is a regular update, but it was previously pinned for causing intermittent breakage when running the unit tests in a browser manually. Fortunately this cannot be reproduced anymore with the most recent version, so we can also put the caret back now.
2022-04-30 19:56:10 +02:00
},
"engines": {
"node": ">=6.0.0"
}
},
Update npm packages
2022-02-06 11:24:14 +01:00
"node_modules/@jridgewell/resolve-uri": {
Update npm packages
2023-03-12 10:27:52 +01:00
"version": "3.1.0",
"resolved": "https://registry.npmjs.org/@jridgewell/resolve-uri/-/resolve-uri-3.1.0.tgz",
"integrity": "sha512-F2msla3tad+Mfht5cJq7LSXcdudKTWCVYUgw6pLFOOHSTtZlj6SWNYAp+AhuqLmWdBO2X5hPrLcu8cVP8fy28w==",
Update npm packages
2022-02-06 11:24:14 +01:00
"dev": true,
"engines": {
"node": ">=6.0.0"
}
},
Update dependencies to the most recent versions There are two notable changes here: - `dommatrix` is a major version upgrade, but looking through the commit history of their `package.json` file at https://github.com/thednp/dommatrix/commits/master/package.json (due to the lack of a changelog) I couldn't find any breaking changes. - `es-module-shims` is a regular update, but it was previously pinned for causing intermittent breakage when running the unit tests in a browser manually. Fortunately this cannot be reproduced anymore with the most recent version, so we can also put the caret back now.
2022-04-30 19:56:10 +02:00
"node_modules/@jridgewell/set-array": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.2.1",
"resolved": "https://registry.npmjs.org/@jridgewell/set-array/-/set-array-1.2.1.tgz",
"integrity": "sha512-R8gLRTZeyp03ymzP/6Lil/28tGeGEzhx1q2k703KGWRAI1VdvPIXdG70VJc2pAMw3NA6JKL5hhFu1sJX0Mnn/A==",
Update dependencies to the most recent versions There are two notable changes here: - `dommatrix` is a major version upgrade, but looking through the commit history of their `package.json` file at https://github.com/thednp/dommatrix/commits/master/package.json (due to the lack of a changelog) I couldn't find any breaking changes. - `es-module-shims` is a regular update, but it was previously pinned for causing intermittent breakage when running the unit tests in a browser manually. Fortunately this cannot be reproduced anymore with the most recent version, so we can also put the caret back now.
2022-04-30 19:56:10 +02:00
"dev": true,
"engines": {
"node": ">=6.0.0"
}
},
Update npm packages
2022-06-12 14:02:31 +02:00
"node_modules/@jridgewell/source-map": {
Update npm packages
2023-06-11 11:30:39 +02:00
"version": "0.3.3",
"resolved": "https://registry.npmjs.org/@jridgewell/source-map/-/source-map-0.3.3.tgz",
"integrity": "sha512-b+fsZXeLYi9fEULmfBrhxn4IrPlINf8fiNarzTof004v3lFdntdwa9PF7vFJqm3mg7s+ScJMxXaE3Acp1irZcg==",
Update npm packages
2022-06-12 14:02:31 +02:00
"dev": true,
"dependencies": {
"@jridgewell/gen-mapping": "^0.3.0",
"@jridgewell/trace-mapping": "^0.3.9"
}
},
Update npm packages
2022-02-06 11:24:14 +01:00
"node_modules/@jridgewell/sourcemap-codec": {
Update npm packages
2023-03-12 10:27:52 +01:00
"version": "1.4.14",
"resolved": "https://registry.npmjs.org/@jridgewell/sourcemap-codec/-/sourcemap-codec-1.4.14.tgz",
"integrity": "sha512-XPSJHWmi394fuUuzDnGz1wiKqWfo1yXecHQMRf2l6hztTO+nPru658AyDngaBe7isIxEkRsPR3FZh+s7iVa4Uw==",
Update npm packages
2022-02-06 11:24:14 +01:00
"dev": true
},
"node_modules/@jridgewell/trace-mapping": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "0.3.25",
"resolved": "https://registry.npmjs.org/@jridgewell/trace-mapping/-/trace-mapping-0.3.25.tgz",
"integrity": "sha512-vNk6aEwybGtawWmy/PzwnGDOjCkLWSD2wqvjGGAgOAwCGWySYXfYoxt00IJkTF+8Lb57DwOb3Aa0o9CApepiYQ==",
Update npm packages
2022-02-06 11:24:14 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"@jridgewell/resolve-uri": "^3.1.0",
"@jridgewell/sourcemap-codec": "^1.4.14"
Update npm packages
2022-02-06 11:24:14 +01:00
}
},
Update npm packages
2022-11-13 21:28:21 +01:00
"node_modules/@jsdoc/salty": {
"version": "0.2.1",
"resolved": "https://registry.npmjs.org/@jsdoc/salty/-/salty-0.2.1.tgz",
"integrity": "sha512-JXwylDNSHa549N9uceDYu8D4GMXwSo3H8CCPYEQqxhhHpxD28+lRl2b3bS/caaPj5w1YD3SWtrficJNTnUjGpg==",
"dev": true,
"dependencies": {
"lodash": "^4.17.21"
},
"engines": {
"node": ">=v12.0.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/@mapbox/node-pre-gyp": {
"version": "1.0.5",
"resolved": "https://registry.npmjs.org/@mapbox/node-pre-gyp/-/node-pre-gyp-1.0.5.tgz",
"integrity": "sha512-4srsKPXWlIxp5Vbqz5uLfBN+du2fJChBoYn/f2h991WLdk7jUvcSk/McVLSv/X+xQIPI8eGD5GjrnygdyHnhPA==",
"dev": true,
"dependencies": {
"detect-libc": "^1.0.3",
"https-proxy-agent": "^5.0.0",
"make-dir": "^3.1.0",
"node-fetch": "^2.6.1",
"nopt": "^5.0.0",
"npmlog": "^4.1.2",
"rimraf": "^3.0.2",
"semver": "^7.3.4",
"tar": "^6.1.0"
},
"bin": {
"node-pre-gyp": "bin/node-pre-gyp"
}
},
"node_modules/@mapbox/node-pre-gyp/node_modules/semver": {
Fix dependency vulnerabilities with `npm audit fix`
2023-10-14 13:46:57 +02:00
"version": "7.5.4",
"resolved": "https://registry.npmjs.org/semver/-/semver-7.5.4.tgz",
"integrity": "sha512-1bCSESV6Pv+i21Hvpxp3Dx+pSD8lIPt8uVjRrxAUt/nbswYc+tK6Y2btiULjd4+fnq15PX+nqQDC7Oft7WkwcA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"lru-cache": "^6.0.0"
},
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"bin": {
"semver": "bin/semver.js"
},
Update npm packages
2022-09-18 10:31:32 +02:00
"engines": {
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"node": ">=10"
Update npm packages
2022-09-18 10:31:32 +02:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/@metalsmith/layouts": {
"version": "2.7.0",
"resolved": "https://registry.npmjs.org/@metalsmith/layouts/-/layouts-2.7.0.tgz",
"integrity": "sha512-VG5ldPSsTxUvHqFQo0u5mjWtS2IUUOqYKHvWnEHKol1UhaXhhYBYSnG0D8kjk+XzGw+mWxNfv/JoAhg94filXA==",
"dev": true,
"license": "MIT",
"dependencies": {
"inputformat-to-jstransformer": "^1.4.0",
"is-utf8": "^0.2.1",
"jstransformer": "^1.0.0"
},
"engines": {
"node": ">=12.0.0"
},
"peerDependencies": {
"metalsmith": "^2.4.1"
}
},
"node_modules/@metalsmith/markdown": {
"version": "1.10.0",
"resolved": "https://registry.npmjs.org/@metalsmith/markdown/-/markdown-1.10.0.tgz",
"integrity": "sha512-DudINS2a9TlYjAVoOpAxlXutyCd6w6pC85RdBmByvkJiYEna+1Qwo3Z2si622URum9saAyG8mGuknoLS0A6beg==",
"dev": true,
"license": "MIT",
"dependencies": {
"dlv": "^1.1.3",
"dset": "^3.1.2",
"marked": "^4.3.0"
},
"engines": {
"node": ">=14.14.0"
},
"peerDependencies": {
"metalsmith": "^2.5.0"
}
},
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"node_modules/@microsoft/eslint-plugin-sdl": {
"version": "0.2.2",
"resolved": "https://registry.npmjs.org/@microsoft/eslint-plugin-sdl/-/eslint-plugin-sdl-0.2.2.tgz",
"integrity": "sha512-TiBepeQMSxHpvIbKA03TbO9nZqRrKR1th47wGdjY1sH2SSer+JgKlSF3S8GURGA8/zp2T/HwSiAJelclJ3hEvg==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true,
"peer": true,
"dependencies": {
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"eslint-plugin-node": "11.1.0",
"eslint-plugin-react": "7.33.0",
"eslint-plugin-security": "1.4.0"
Update npm packages
2022-09-18 10:31:32 +02:00
},
"engines": {
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"node": ">=0.10.0"
},
"peerDependencies": {
"eslint": "^4.19.1 || ^5 || ^6 || ^7 || ^8"
Update npm packages
2022-09-18 10:31:32 +02:00
}
},
"node_modules/@nodelib/fs.scandir": {
"version": "2.1.5",
"resolved": "https://registry.npmjs.org/@nodelib/fs.scandir/-/fs.scandir-2.1.5.tgz",
"integrity": "sha512-vq24Bq3ym5HEQm2NKCr3yXDwjc7vTsEThRDnkp2DK9p1uqLR+DHurm/NOTo0KG7HYHU7eppKZj3MyqYuMBf62g==",
"dev": true,
"dependencies": {
"@nodelib/fs.stat": "2.0.5",
"run-parallel": "^1.1.9"
},
"engines": {
"node": ">= 8"
}
},
"node_modules/@nodelib/fs.stat": {
"version": "2.0.5",
"resolved": "https://registry.npmjs.org/@nodelib/fs.stat/-/fs.stat-2.0.5.tgz",
"integrity": "sha512-RkhPPp2zrqDAQA/2jNhnztcPAlv64XdhIp7a7454A5ovI7Bukxgt7MX7udwAu3zg1DcpPU0rz3VV1SeaqvY4+A==",
"dev": true,
"engines": {
"node": ">= 8"
}
},
"node_modules/@nodelib/fs.walk": {
"version": "1.2.8",
"resolved": "https://registry.npmjs.org/@nodelib/fs.walk/-/fs.walk-1.2.8.tgz",
"integrity": "sha512-oGB+UxlgWcgQkgwo8GcEGwemoTFt3FIO9ababBmaGwXIoBKZ+GTy0pP185beGg7Llih/NSHSV2XAs1lnznocSg==",
"dev": true,
"dependencies": {
"@nodelib/fs.scandir": "2.1.5",
"fastq": "^1.6.0"
},
"engines": {
"node": ">= 8"
}
},
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node_modules/@pkgjs/parseargs": {
"version": "0.11.0",
"resolved": "https://registry.npmjs.org/@pkgjs/parseargs/-/parseargs-0.11.0.tgz",
"integrity": "sha512-+1VkjdD0QBLPodGrJUeqarH8VAIvQODIbwh9XpP5Syisf7YoQgsJKPNFoqqLQlu+VQ/tVSshMR6loPMn8U+dPg==",
"dev": true,
"optional": true,
"engines": {
"node": ">=14"
}
},
Update npm packages
2024-01-06 10:09:12 +01:00
"node_modules/@pkgr/core": {
"version": "0.1.0",
"resolved": "https://registry.npmjs.org/@pkgr/core/-/core-0.1.0.tgz",
"integrity": "sha512-Zwq5OCzuwJC2jwqmpEQt7Ds1DTi6BWSwoGkbb1n9pO3hzb35BoJELx7c0T23iDkBGkh2e7tvOtjF3tr3OaQHDQ==",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"dev": true,
"engines": {
"node": "^12.20.0 || ^14.18.0 || >=16.0.0"
},
"funding": {
"url": "https://opencollective.com/unts"
}
},
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"node_modules/@puppeteer/browsers": {
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"version": "2.2.3",
"resolved": "https://registry.npmjs.org/@puppeteer/browsers/-/browsers-2.2.3.tgz",
"integrity": "sha512-bJ0UBsk0ESOs6RFcLXOt99a3yTDcOKlzfjad+rhFwdaG1Lu/Wzq58GHYCDTlZ9z6mldf4g+NTb+TXEfe0PpnsQ==",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "Apache-2.0",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dependencies": {
"debug": "4.3.4",
"extract-zip": "2.0.1",
"progress": "2.0.3",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"proxy-agent": "6.4.0",
"semver": "7.6.0",
"tar-fs": "3.0.5",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"unbzip2-stream": "1.4.3",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"yargs": "17.7.2"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
},
"bin": {
"browsers": "lib/cjs/main-cli.js"
},
"engines": {
Update `puppeteer` to version 22.0.0 This is a major version bump that requires two changes on our side: - The new headless mode is now the default, so we can remove our transformation code (see https://github.com/puppeteer/puppeteer/pull/11815). - The `page.waitForTimeout` API is removed. Sadly we still used it in the integration tests (but fortunately much less than before we worked on fixing intermittent failures), so until we remove the final occurrences we provide an implementation ourselves (see https://github.com/puppeteer/puppeteer/pull/11780). The full changelog can be found here: https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.0.0
2024-02-10 18:21:34 +01:00
"node": ">=18"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
}
},
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"node_modules/@puppeteer/browsers/node_modules/semver": {
"version": "7.6.0",
"resolved": "https://registry.npmjs.org/semver/-/semver-7.6.0.tgz",
"integrity": "sha512-EnwXhrlwXMk9gKu5/flx5sv/an57AkRplG3hTK68W7FRDN+k+OWBj65M7719OkA82XLBxrcX0KSHj+X5COhOVg==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "ISC",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"dependencies": {
"lru-cache": "^6.0.0"
},
"bin": {
"semver": "bin/semver.js"
},
"engines": {
"node": ">=10"
}
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/@tootallnate/quickjs-emscripten": {
"version": "0.23.0",
"resolved": "https://registry.npmjs.org/@tootallnate/quickjs-emscripten/-/quickjs-emscripten-0.23.0.tgz",
"integrity": "sha512-C5Mc6rdnsaJDjO3UpGW/CQTHtCKaYlScZTly4JIu97Jxo/odCiH0ITnDXSJPTOrEKk/ycSZ0AOgTmkDtkOsvIA==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "MIT"
Update npm packages
2023-07-23 09:49:53 +02:00
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/@types/eslint": {
"version": "8.4.1",
"resolved": "https://registry.npmjs.org/@types/eslint/-/eslint-8.4.1.tgz",
"integrity": "sha512-GE44+DNEyxxh2Kc6ro/VkIj+9ma0pO0bwv9+uHSyBrikYOHr8zYcdPvnBOp1aw8s+CjRvuSx7CyWqRrNFQ59mA==",
"dev": true,
"dependencies": {
"@types/estree": "*",
"@types/json-schema": "*"
}
},
"node_modules/@types/eslint-scope": {
"version": "3.7.3",
"resolved": "https://registry.npmjs.org/@types/eslint-scope/-/eslint-scope-3.7.3.tgz",
"integrity": "sha512-PB3ldyrcnAicT35TWPs5IcwKD8S333HMaa2VVv4+wdvebJkjWuW/xESoB8IwRcog8HYVYamb1g/R31Qv5Bx03g==",
"dev": true,
"dependencies": {
"@types/eslint": "*",
"@types/estree": "*"
}
},
"node_modules/@types/estree": {
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"version": "1.0.5",
"resolved": "https://registry.npmjs.org/@types/estree/-/estree-1.0.5.tgz",
"integrity": "sha512-/kYRxGDLWzHOB7q+wtSUQlFrtcdUccpfy+X+9iMBpHK8QLLhx2wIPYuS5DYtR9Wa/YlZAbIovy7qVdB1Aq6Lyw==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true
},
"node_modules/@types/expect": {
"version": "1.20.4",
"resolved": "https://registry.npmjs.org/@types/expect/-/expect-1.20.4.tgz",
"integrity": "sha512-Q5Vn3yjTDyCMV50TB6VRIbQNxSE4OmZR86VSbGaNpfUolm0iePBB4KdEEHmxoY5sT2+2DIvXW0rvMDP2nHZ4Mg==",
"dev": true
},
"node_modules/@types/json-schema": {
"version": "7.0.9",
"resolved": "https://registry.npmjs.org/@types/json-schema/-/json-schema-7.0.9.tgz",
"integrity": "sha512-qcUXuemtEu+E5wZSJHNxUXeCZhAfXKQ41D+duX+VYPde7xyEVZci+/oXKJL13tnRs9lR2pr4fod59GT6/X1/yQ==",
"dev": true
},
"node_modules/@types/json5": {
"version": "0.0.29",
"resolved": "https://registry.npmjs.org/@types/json5/-/json5-0.0.29.tgz",
Update npm packages
2023-08-06 09:22:20 +02:00
"integrity": "sha512-dRLjCWHYg4oaA77cxO64oO+7JwCwnIzkZPdrrC71jQmQtlhM556pwKo5bUzqvZndkVbeFLIIi+9TC40JNF5hNQ==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true
},
"node_modules/@types/linkify-it": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/@types/linkify-it/-/linkify-it-5.0.0.tgz",
"integrity": "sha512-sVDA58zAw4eWAffKOaQH5/5j3XeayukzDk+ewSsnv3p4yJEZHCCzMDiZM8e0OUrRvmpGZ85jf4yDHkHsgBNr9Q==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true
},
"node_modules/@types/markdown-it": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"version": "14.1.1",
"resolved": "https://registry.npmjs.org/@types/markdown-it/-/markdown-it-14.1.1.tgz",
"integrity": "sha512-4NpsnpYl2Gt1ljyBGrKMxFYAYvpqbnnkgP/i/g+NLpjEUa3obn1XJCur9YbEXKDAkaXqsR1LbDnGEJ0MmKFxfg==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"@types/linkify-it": "^5",
"@types/mdurl": "^2"
Update npm packages
2022-09-18 10:31:32 +02:00
}
},
"node_modules/@types/mdurl": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/@types/mdurl/-/mdurl-2.0.0.tgz",
"integrity": "sha512-RGdgjQUZba5p6QEFAVx2OGb8rQDL/cPRG7GiedRzMcJ1tYnUANBncjbSB1NRGwbvjcPeikRABz2nshyPk1bhWg==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true
},
"node_modules/@types/node": {
"version": "14.14.45",
"resolved": "https://registry.npmjs.org/@types/node/-/node-14.14.45.tgz",
"integrity": "sha512-DssMqTV9UnnoxDWu959sDLZzfvqCF0qDNRjaWeYSui9xkFe61kKo4l1TWNTQONpuXEm+gLMRvdlzvNHBamzmEw==",
"dev": true
},
"node_modules/@types/normalize-package-data": {
"version": "2.4.0",
"resolved": "https://registry.npmjs.org/@types/normalize-package-data/-/normalize-package-data-2.4.0.tgz",
"integrity": "sha512-f5j5b/Gf71L+dbqxIpQ4Z2WlmI/mPJ0fOkGGmFgtb6sAu97EPczzbS3/tJKxmcYDj55OX6ssqwDAWOHIYDRDGA==",
"dev": true
},
"node_modules/@types/vinyl": {
Update npm packages The new major version of `gulp-zip` shouldn't be a problem, given the changes listed in https://github.com/sindresorhus/gulp-zip/releases/tag/v6.0.0
2023-11-04 09:30:39 +01:00
"version": "2.0.9",
"resolved": "https://registry.npmjs.org/@types/vinyl/-/vinyl-2.0.9.tgz",
"integrity": "sha512-KCr4aTEUkzSF89qw09e2oxsC/RXXT3K5ZPv4gvj3XTiWVrxNoi7WrqNTahNE/Hul5C9z3B8w+yWNTQgua12oag==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true,
"dependencies": {
"@types/expect": "^1.20.4",
"@types/node": "*"
}
},
"node_modules/@types/yauzl": {
Update dependencies to the most recent versions
2023-11-11 15:57:28 +01:00
"version": "2.10.3",
"resolved": "https://registry.npmjs.org/@types/yauzl/-/yauzl-2.10.3.tgz",
"integrity": "sha512-oJoftv0LSuaDZE3Le4DbKX+KS9G36NzOeSap90UIK0yMA/NhKJhqlSGtNDORNRaIbQfzjXDrQa0ytJ6mNRGz/Q==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2022-09-18 10:31:32 +02:00
"optional": true,
"dependencies": {
"@types/node": "*"
}
},
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"node_modules/@ungap/structured-clone": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/@ungap/structured-clone/-/structured-clone-1.2.0.tgz",
"integrity": "sha512-zuVdFrMJiuCDQUMCzQaD6KL28MjnqqN8XnAqiEq9PNm/hCPTSGfrXCOfwj1ow4LFb/tNymJPwsNbVePc1xFqrQ==",
"dev": true
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/@webassemblyjs/ast": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.12.1",
"resolved": "https://registry.npmjs.org/@webassemblyjs/ast/-/ast-1.12.1.tgz",
"integrity": "sha512-EKfMUOPRRUTy5UII4qJDGPpqfwjOmZ5jeGFwid9mnoqIFK+e0vqoi1qH56JpmZSzEL53jKnNzScdmftJyG5xWg==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@webassemblyjs/helper-numbers": "1.11.6",
"@webassemblyjs/helper-wasm-bytecode": "1.11.6"
Update npm packages
2022-09-18 10:31:32 +02:00
}
},
"node_modules/@webassemblyjs/floating-point-hex-parser": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.11.6",
"resolved": "https://registry.npmjs.org/@webassemblyjs/floating-point-hex-parser/-/floating-point-hex-parser-1.11.6.tgz",
"integrity": "sha512-ejAj9hfRJ2XMsNHk/v6Fu2dGS+i4UaXBXGemOfQ/JfQ6mdQg/WXtwleQRLLS4OvfDhv8rYnVwH27YJLMyYsxhw==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"node_modules/@webassemblyjs/helper-api-error": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.11.6",
"resolved": "https://registry.npmjs.org/@webassemblyjs/helper-api-error/-/helper-api-error-1.11.6.tgz",
"integrity": "sha512-o0YkoP4pVu4rN8aTJgAyj9hC2Sv5UlkzCHhxqWj8butaLvnpdc2jOwh4ewE6CX0txSfLn/UYaV/pheS2Txg//Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
"node_modules/@webassemblyjs/helper-buffer": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.12.1",
"resolved": "https://registry.npmjs.org/@webassemblyjs/helper-buffer/-/helper-buffer-1.12.1.tgz",
"integrity": "sha512-nzJwQw99DNDKr9BVCOZcLuJJUlqkJh+kVzVl6Fmq/tI5ZtEyWT1KZMyOXltXLZJmDtvLCDgwsyrkohEtopTXCw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
"node_modules/@webassemblyjs/helper-numbers": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.11.6",
"resolved": "https://registry.npmjs.org/@webassemblyjs/helper-numbers/-/helper-numbers-1.11.6.tgz",
"integrity": "sha512-vUIhZ8LZoIWHBohiEObxVm6hwP034jwmc9kuq5GdHZH0wiLVLIPcMCdpJzG4C11cHoQ25TFIQj9kaVADVX7N3g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@webassemblyjs/floating-point-hex-parser": "1.11.6",
"@webassemblyjs/helper-api-error": "1.11.6",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"@xtuc/long": "4.2.2"
}
},
"node_modules/@webassemblyjs/helper-wasm-bytecode": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.11.6",
"resolved": "https://registry.npmjs.org/@webassemblyjs/helper-wasm-bytecode/-/helper-wasm-bytecode-1.11.6.tgz",
"integrity": "sha512-sFFHKwcmBprO9e7Icf0+gddyWYDViL8bpPjJJl0WHxCdETktXdmtWLGVzoHbqUcY4Be1LkNfwTmXOJUFZYSJdA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
"node_modules/@webassemblyjs/helper-wasm-section": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.12.1",
"resolved": "https://registry.npmjs.org/@webassemblyjs/helper-wasm-section/-/helper-wasm-section-1.12.1.tgz",
"integrity": "sha512-Jif4vfB6FJlUlSbgEMHUyk1j234GTNG9dBJ4XJdOySoj518Xj0oGsNi59cUQF4RRMS9ouBUxDDdyBVfPTypa5g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@webassemblyjs/ast": "1.12.1",
"@webassemblyjs/helper-buffer": "1.12.1",
"@webassemblyjs/helper-wasm-bytecode": "1.11.6",
"@webassemblyjs/wasm-gen": "1.12.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/@webassemblyjs/ieee754": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.11.6",
"resolved": "https://registry.npmjs.org/@webassemblyjs/ieee754/-/ieee754-1.11.6.tgz",
"integrity": "sha512-LM4p2csPNvbij6U1f19v6WR56QZ8JcHg3QIJTlSwzFcmx6WSORicYj6I63f9yU1kEUtrpG+kjkiIAkevHpDXrg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"@xtuc/ieee754": "^1.2.0"
}
},
"node_modules/@webassemblyjs/leb128": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.11.6",
"resolved": "https://registry.npmjs.org/@webassemblyjs/leb128/-/leb128-1.11.6.tgz",
"integrity": "sha512-m7a0FhE67DQXgouf1tbN5XQcdWoNgaAuoULHIfGFIEVKA6tu/edls6XnIlkmS6FrXAquJRPni3ZZKjw6FSPjPQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"@xtuc/long": "4.2.2"
}
},
"node_modules/@webassemblyjs/utf8": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.11.6",
"resolved": "https://registry.npmjs.org/@webassemblyjs/utf8/-/utf8-1.11.6.tgz",
"integrity": "sha512-vtXf2wTQ3+up9Zsg8sa2yWiQpzSsMyXj0qViVP6xKGCUT8p8YJ6HqI7l5eCnWx1T/FYdsv07HQs2wTFbbof/RA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
"node_modules/@webassemblyjs/wasm-edit": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.12.1",
"resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-edit/-/wasm-edit-1.12.1.tgz",
"integrity": "sha512-1DuwbVvADvS5mGnXbE+c9NfA8QRcZ6iKquqjjmR10k6o+zzsRVesil54DKexiowcFCPdr/Q0qaMgB01+SQ1u6g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@webassemblyjs/ast": "1.12.1",
"@webassemblyjs/helper-buffer": "1.12.1",
"@webassemblyjs/helper-wasm-bytecode": "1.11.6",
"@webassemblyjs/helper-wasm-section": "1.12.1",
"@webassemblyjs/wasm-gen": "1.12.1",
"@webassemblyjs/wasm-opt": "1.12.1",
"@webassemblyjs/wasm-parser": "1.12.1",
"@webassemblyjs/wast-printer": "1.12.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/@webassemblyjs/wasm-gen": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.12.1",
"resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-gen/-/wasm-gen-1.12.1.tgz",
"integrity": "sha512-TDq4Ojh9fcohAw6OIMXqiIcTq5KUXTGRkVxbSo1hQnSy6lAM5GSdfwWeSxpAo0YzgsgF182E/U0mDNhuA0tW7w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@webassemblyjs/ast": "1.12.1",
"@webassemblyjs/helper-wasm-bytecode": "1.11.6",
"@webassemblyjs/ieee754": "1.11.6",
"@webassemblyjs/leb128": "1.11.6",
"@webassemblyjs/utf8": "1.11.6"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/@webassemblyjs/wasm-opt": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.12.1",
"resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-opt/-/wasm-opt-1.12.1.tgz",
"integrity": "sha512-Jg99j/2gG2iaz3hijw857AVYekZe2SAskcqlWIZXjji5WStnOpVoat3gQfT/Q5tb2djnCjBtMocY/Su1GfxPBg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@webassemblyjs/ast": "1.12.1",
"@webassemblyjs/helper-buffer": "1.12.1",
"@webassemblyjs/wasm-gen": "1.12.1",
"@webassemblyjs/wasm-parser": "1.12.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/@webassemblyjs/wasm-parser": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.12.1",
"resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-parser/-/wasm-parser-1.12.1.tgz",
"integrity": "sha512-xikIi7c2FHXysxXe3COrVUPSheuBtpcfhbpFj4gmu7KRLYOzANztwUU0IbsqvMqzuNK2+glRGWCEqZo1WCLyAQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@webassemblyjs/ast": "1.12.1",
"@webassemblyjs/helper-api-error": "1.11.6",
"@webassemblyjs/helper-wasm-bytecode": "1.11.6",
"@webassemblyjs/ieee754": "1.11.6",
"@webassemblyjs/leb128": "1.11.6",
"@webassemblyjs/utf8": "1.11.6"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/@webassemblyjs/wast-printer": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.12.1",
"resolved": "https://registry.npmjs.org/@webassemblyjs/wast-printer/-/wast-printer-1.12.1.tgz",
"integrity": "sha512-+X4WAlOisVWQMikjbcvY2e0rwPsKQ9F688lksZhBcPycBBuii3O7m8FACbDMWDojpAqvjIncrG8J0XHKyQfVeA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@webassemblyjs/ast": "1.12.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"@xtuc/long": "4.2.2"
}
},
"node_modules/@xtuc/ieee754": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/@xtuc/ieee754/-/ieee754-1.2.0.tgz",
"integrity": "sha512-DX8nKgqcGwsc0eJSqYt5lwP4DH5FlHnmuWWBRy7X0NcaGR0ZtuyeESgMwTYVEtxmsNGY+qit4QYT/MIYTOTPeA==",
"dev": true
},
"node_modules/@xtuc/long": {
"version": "4.2.2",
"resolved": "https://registry.npmjs.org/@xtuc/long/-/long-4.2.2.tgz",
"integrity": "sha512-NuHqBY1PB/D8xU6s/thBgOAiAP7HOYDQ32+BFZILJ8ivkUkAHQnWfn6WhL79Owj1qmUnoN/YPhktdIoucipkAQ==",
"dev": true
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/a-sync-waterfall": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/a-sync-waterfall/-/a-sync-waterfall-1.0.1.tgz",
"integrity": "sha512-RYTOHHdWipFUliRFMCS4X2Yn2X8M87V/OpSqWzKKOGhzqyUxzyVmhHDH9sAvG+ZuQf/TAOFsLCpMw09I1ufUnA==",
"dev": true,
"license": "MIT"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/abbrev": {
"version": "1.1.1",
"resolved": "https://registry.npmjs.org/abbrev/-/abbrev-1.1.1.tgz",
"integrity": "sha512-nne9/IiQ/hzIhY6pdDnbBtz7DjPTKrY00P/zvPSm5pOFkl6xuGrGnXn/VtTNNfNtAfZ9/1RtehkszU9qcTii0Q==",
"dev": true
},
"node_modules/acorn": {
Update npm packages
2024-01-06 10:09:12 +01:00
"version": "8.11.3",
"resolved": "https://registry.npmjs.org/acorn/-/acorn-8.11.3.tgz",
"integrity": "sha512-Y9rRfJG5jcKOE0CLisYbojUjIrIEE7AGMzA/Sm4BslANhbS+cDMpgBdcPT91oJ7OuJ9hYJBx59RjbhxVnrF8Xg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"bin": {
"acorn": "bin/acorn"
},
"engines": {
"node": ">=0.4.0"
}
},
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"node_modules/acorn-import-attributes": {
"version": "1.9.5",
"resolved": "https://registry.npmjs.org/acorn-import-attributes/-/acorn-import-attributes-1.9.5.tgz",
"integrity": "sha512-n02Vykv5uA3eHGM/Z2dQrcD56kL8TyDb2p1+0P83PClMnC/nc+anbQRhIOWnSq4Ke/KvDPrY3C9hDtC/A3eHnQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"peerDependencies": {
"acorn": "^8"
}
},
"node_modules/acorn-jsx": {
Update packages to the most recent versions
2021-12-11 15:24:26 +01:00
"version": "5.3.2",
"resolved": "https://registry.npmjs.org/acorn-jsx/-/acorn-jsx-5.3.2.tgz",
"integrity": "sha512-rq9s+JNhf0IChjtDXxllJ7g41oZk5SlXtp0LHwyA5cejwn7vKmKp4pPri6YEePv2PU65sAsegbXtIinmDFDXgQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"peerDependencies": {
"acorn": "^6.0.0 || ^7.0.0 || ^8.0.0"
}
},
"node_modules/agent-base": {
"version": "6.0.2",
"resolved": "https://registry.npmjs.org/agent-base/-/agent-base-6.0.2.tgz",
"integrity": "sha512-RZNwNclF7+MS/8bDg70amg32dyeZGZxiDuQmZxKLAlQjr3jGyLx+4Kkk58UO7D2QdgFIQCovuSuZESne6RG6XQ==",
"dev": true,
"dependencies": {
"debug": "4"
},
"engines": {
"node": ">= 6.0.0"
}
},
"node_modules/ajv": {
"version": "6.12.6",
"resolved": "https://registry.npmjs.org/ajv/-/ajv-6.12.6.tgz",
"integrity": "sha512-j3fVLgvTo527anyYyJOGTYJbG+vnnQYvE0m5mmkc1TK+nxAppkCLMIL0aZ4dblVCNoGShhm+kzE4ZUykBoMg4g==",
"dev": true,
"dependencies": {
"fast-deep-equal": "^3.1.1",
"fast-json-stable-stringify": "^2.0.0",
"json-schema-traverse": "^0.4.1",
"uri-js": "^4.2.2"
},
"funding": {
"type": "github",
"url": "https://github.com/sponsors/epoberezkin"
}
},
Update npm packages
2022-10-29 10:17:36 +02:00
"node_modules/ajv-formats": {
"version": "2.1.1",
"resolved": "https://registry.npmjs.org/ajv-formats/-/ajv-formats-2.1.1.tgz",
"integrity": "sha512-Wx0Kx52hxE7C18hkMEggYlEifqWZtYaRgouJor+WMdPnQyEK13vgEWyVNup7SoeeoLMsr4kf5h6dOW11I15MUA==",
"dev": true,
"dependencies": {
"ajv": "^8.0.0"
},
"peerDependencies": {
"ajv": "^8.0.0"
},
"peerDependenciesMeta": {
"ajv": {
"optional": true
}
}
},
"node_modules/ajv-formats/node_modules/ajv": {
"version": "8.11.0",
"resolved": "https://registry.npmjs.org/ajv/-/ajv-8.11.0.tgz",
"integrity": "sha512-wGgprdCvMalC0BztXvitD2hC04YffAvtsUn93JbGXYLAtCUO4xd17mCCZQxUOItiBwZvJScWo8NIvQMQ71rdpg==",
"dev": true,
"dependencies": {
"fast-deep-equal": "^3.1.1",
"json-schema-traverse": "^1.0.0",
"require-from-string": "^2.0.2",
"uri-js": "^4.2.2"
},
"funding": {
"type": "github",
"url": "https://github.com/sponsors/epoberezkin"
}
},
"node_modules/ajv-formats/node_modules/json-schema-traverse": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz",
"integrity": "sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==",
"dev": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/ajv-keywords": {
"version": "3.5.2",
"resolved": "https://registry.npmjs.org/ajv-keywords/-/ajv-keywords-3.5.2.tgz",
"integrity": "sha512-5p6WTN0DdTGVQk6VjcEju19IgaHudalcfabD7yhDGeA6bcQnmL+CpveLJq/3hvfwd1aof6L386Ougkx6RfyMIQ==",
"dev": true,
"peerDependencies": {
"ajv": "^6.9.1"
}
},
"node_modules/ansi-colors": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/ansi-colors/-/ansi-colors-1.1.0.tgz",
"integrity": "sha512-SFKX67auSNoVR38N3L+nvsPjOE0bybKTYbkf5tRvushrAPQ9V75huw0ZxBkKVeRU9kqH3d6HA4xTckbwZ4ixmA==",
"dev": true,
"dependencies": {
"ansi-wrap": "^0.1.0"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/ansi-gray": {
"version": "0.1.1",
"resolved": "https://registry.npmjs.org/ansi-gray/-/ansi-gray-0.1.1.tgz",
"integrity": "sha1-KWLPVOyXksSFEKPetSRDaGHvclE=",
"dev": true,
"dependencies": {
"ansi-wrap": "0.1.0"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/ansi-regex": {
"version": "2.1.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-2.1.1.tgz",
"integrity": "sha1-w7M6te42DYbg5ijwRorn7yfWVN8=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/ansi-styles": {
"version": "3.2.1",
"resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-3.2.1.tgz",
"integrity": "sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==",
"dev": true,
"dependencies": {
"color-convert": "^1.9.0"
},
"engines": {
"node": ">=4"
}
},
"node_modules/ansi-wrap": {
"version": "0.1.0",
"resolved": "https://registry.npmjs.org/ansi-wrap/-/ansi-wrap-0.1.0.tgz",
"integrity": "sha1-qCJQ3bABXponyoLoLqYDu/pF768=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/append-transform": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/append-transform/-/append-transform-2.0.0.tgz",
"integrity": "sha512-7yeyCEurROLQJFv5Xj4lEGTy0borxepjFv1g22oAdqFu//SrAlDl1O1Nxx15SH1RoliUml6p8dwJW9jvZughhg==",
"dev": true,
"dependencies": {
"default-require-extensions": "^3.0.0"
},
"engines": {
"node": ">=8"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/aproba": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/aproba/-/aproba-1.2.0.tgz",
"integrity": "sha512-Y9J6ZjXtoYh8RnXVCMOU/ttDmk1aBjunq9vO0ta5x85WDQiQfUF9sIPBITdbiiIVcBo03Hi3jMxigBtsddlXRw==",
"dev": true
},
"node_modules/are-we-there-yet": {
"version": "1.1.5",
"resolved": "https://registry.npmjs.org/are-we-there-yet/-/are-we-there-yet-1.1.5.tgz",
"integrity": "sha512-5hYdAkZlcG8tOLujVDTgCT+uPX0VnpAH28gWsLfzpXYm7wP6mp5Q/gYyR7YQ0cKVJcXJnl3j2kpBan13PtQf6w==",
"dev": true,
"dependencies": {
"delegates": "^1.0.0",
"readable-stream": "^2.0.6"
}
},
"node_modules/argparse": {
"version": "1.0.10",
"resolved": "https://registry.npmjs.org/argparse/-/argparse-1.0.10.tgz",
"integrity": "sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==",
"dev": true,
"dependencies": {
"sprintf-js": "~1.0.2"
}
},
"node_modules/arr-diff": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/arr-diff/-/arr-diff-4.0.0.tgz",
"integrity": "sha1-1kYQdP6/7HHn4VI1dhoyml3HxSA=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/arr-union": {
"version": "3.1.0",
"resolved": "https://registry.npmjs.org/arr-union/-/arr-union-3.1.0.tgz",
"integrity": "sha1-45sJrqne+Gao8gbiiK9jkZuuOcQ=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
Update npm packages
2023-08-06 09:22:20 +02:00
"node_modules/array-buffer-byte-length": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/array-buffer-byte-length/-/array-buffer-byte-length-1.0.0.tgz",
"integrity": "sha512-LPuwb2P+NrQw3XhxGc36+XSvuBPopovXYTR9Ew++Du9Yb/bx5AzBfrIsBoj0EZUifjQU+sHL21sseZ3jerWO/A==",
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
"is-array-buffer": "^3.0.1"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/array-each": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/array-each/-/array-each-1.0.1.tgz",
"integrity": "sha1-p5SvDAWrF1KEbudTofIRoFugxE8=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/array-includes": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"version": "3.1.7",
"resolved": "https://registry.npmjs.org/array-includes/-/array-includes-3.1.7.tgz",
"integrity": "sha512-dlcsNBIiWhPkHdOEEKnehA+RNUWDc4UqFtnIXU4uuYDPtA4LDkr7qip2p0VvFAEXNDr0yWZ9PJyIRiGjRLQzwQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"define-properties": "^1.2.0",
"es-abstract": "^1.22.1",
"get-intrinsic": "^1.2.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"is-string": "^1.0.7"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/array-slice": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/array-slice/-/array-slice-1.1.0.tgz",
"integrity": "sha512-B1qMD3RBP7O8o0H2KbrXDyB0IccejMF15+87Lvlor12ONPRHP6gTjXMNkt/d3ZuOGbAe66hFmaCfECI24Ufp6w==",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/array-union": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/array-union/-/array-union-2.1.0.tgz",
"integrity": "sha512-HGyxoOTYUyCM6stUe6EJgnd4EoewAI7zMdfqO+kGjnlZmBDz/cR5pf8r/cR4Wq60sL/p0IkcjUEEPwS3GFrIyw==",
"dev": true,
"engines": {
"node": ">=8"
}
},
Update npm packages
2023-08-06 09:22:20 +02:00
"node_modules/array.prototype.findlastindex": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"version": "1.2.3",
"resolved": "https://registry.npmjs.org/array.prototype.findlastindex/-/array.prototype.findlastindex-1.2.3.tgz",
"integrity": "sha512-LzLoiOMAxvy+Gd3BAq3B7VeIgPdo+Q8hthvKtXybMvRV0jrXfJM/t8mw7nNlpEcVlVUnCnM2KSX4XU5HmpodOA==",
Update npm packages
2023-08-06 09:22:20 +02:00
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"define-properties": "^1.2.0",
"es-abstract": "^1.22.1",
Update npm packages
2023-08-06 09:22:20 +02:00
"es-shim-unscopables": "^1.0.0",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"get-intrinsic": "^1.2.1"
Update npm packages
2023-08-06 09:22:20 +02:00
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/array.prototype.flat": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"version": "1.3.2",
"resolved": "https://registry.npmjs.org/array.prototype.flat/-/array.prototype.flat-1.3.2.tgz",
"integrity": "sha512-djYB+Zx2vLewY8RWlNCUdHjDXs2XOgm602S9E7P/UpHgfeHL00cRiIF+IN/G/aUJ7kGPb6yO/ErDI5V2s8iycA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"define-properties": "^1.2.0",
"es-abstract": "^1.22.1",
Update npm packages
2023-01-15 10:34:56 +01:00
"es-shim-unscopables": "^1.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/array.prototype.flatmap": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"version": "1.3.2",
"resolved": "https://registry.npmjs.org/array.prototype.flatmap/-/array.prototype.flatmap-1.3.2.tgz",
"integrity": "sha512-Ewyx0c9PmpcsByhSW4r+9zDU7sGjFc86qf/kKtuSCRdhfbk0SNLLkaT5qvcHnRGgc5NP/ly/y+qkXkqONX54CQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2022-09-18 10:31:32 +02:00
"call-bind": "^1.0.2",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"define-properties": "^1.2.0",
"es-abstract": "^1.22.1",
Update npm packages
2022-09-18 10:31:32 +02:00
"es-shim-unscopables": "^1.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">= 0.4"
Update npm packages
2022-09-18 10:31:32 +02:00
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"node_modules/array.prototype.tosorted": {
"version": "1.1.2",
"resolved": "https://registry.npmjs.org/array.prototype.tosorted/-/array.prototype.tosorted-1.1.2.tgz",
"integrity": "sha512-HuQCHOlk1Weat5jzStICBCd83NxiIMwqDg/dHEsoefabn/hJRj5pVdWcPUSpRrwhwxZOsQassMpgN/xRYFBMIg==",
"dev": true,
"peer": true,
"dependencies": {
"call-bind": "^1.0.2",
"define-properties": "^1.2.0",
"es-abstract": "^1.22.1",
"es-shim-unscopables": "^1.0.0",
"get-intrinsic": "^1.2.1"
}
},
Update npm packages
2023-08-06 09:22:20 +02:00
"node_modules/arraybuffer.prototype.slice": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/arraybuffer.prototype.slice/-/arraybuffer.prototype.slice-1.0.1.tgz",
"integrity": "sha512-09x0ZWFEjj4WD8PDbykUwo3t9arLn8NIzmmYEJFpYekOAQjpkGSyrQhNoRTcwwcFRu+ycWF78QZ63oWTqSjBcw==",
"dev": true,
"dependencies": {
"array-buffer-byte-length": "^1.0.0",
"call-bind": "^1.0.2",
"define-properties": "^1.2.0",
"get-intrinsic": "^1.2.1",
"is-array-buffer": "^3.0.2",
"is-shared-array-buffer": "^1.0.2"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/asap": {
"version": "2.0.6",
"resolved": "https://registry.npmjs.org/asap/-/asap-2.0.6.tgz",
"integrity": "sha1-5QNHYR1+aQlDIIu9r+vLwvuGbUY=",
"dev": true
},
"node_modules/assign-symbols": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/assign-symbols/-/assign-symbols-1.0.0.tgz",
"integrity": "sha1-WWZ/QfrdTyDMvCu5a41Pf3jsA2c=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/ast-types": {
"version": "0.13.4",
"resolved": "https://registry.npmjs.org/ast-types/-/ast-types-0.13.4.tgz",
"integrity": "sha512-x1FCFnFifvYDDzTaLII71vG5uvDwgtmDTEVWAxrgeiR8VjMONcCXJx7E+USjDtHlwFmt9MysbqgF9b9Vjr6w+w==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"tslib": "^2.0.1"
},
"engines": {
"node": ">=4"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/astral-regex": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/astral-regex/-/astral-regex-2.0.0.tgz",
"integrity": "sha512-Z7tMw1ytTXt5jqMcOP+OQteU1VuNK9Y02uuJtKQ1Sv69jXQKKg5cibLwGJow8yzZP+eAc18EmLGPal0bp36rvQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/async-done": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/async-done/-/async-done-2.0.0.tgz",
"integrity": "sha512-j0s3bzYq9yKIVLKGE/tWlCpa3PfFLcrDZLTSVdnnCTGagXuXBJO4SsY9Xdk/fQBirCkH4evW5xOeJXqlAQFdsw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"end-of-stream": "^1.4.4",
"once": "^1.4.0",
"stream-exhaust": "^1.0.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/async-settle": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/async-settle/-/async-settle-2.0.0.tgz",
"integrity": "sha512-Obu/KE8FurfQRN6ODdHN9LuXqwC+JFIM9NRyZqJJ4ZfLJmIYN9Rg0/kb+wF70VV5+fJusTMQlJ1t5rF7J/ETdg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"async-done": "^2.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/asynckit": {
"version": "0.4.0",
"resolved": "https://registry.npmjs.org/asynckit/-/asynckit-0.4.0.tgz",
"integrity": "sha512-Oei9OH4tRh0YqU3GxhX79dM/mwVgvbZJaSNaRk+bshkj0S5cfHcgYakreBjrHwatXKbz+IoIdYLxrKim2MjW0Q==",
"dev": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/autoprefixer": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "10.4.19",
"resolved": "https://registry.npmjs.org/autoprefixer/-/autoprefixer-10.4.19.tgz",
"integrity": "sha512-BaENR2+zBZ8xXhM4pUaKUxlVdxZ0EZhjvbopwnXmxRUfqDmwSpC2lAi/QXvx7NRdPCo1WKEcEF6mV64si1z4Ew==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update npm packages Note that the Prettier update made it possible to move a couple of comments after `default:`-cases back to their original/intended positions, please see https://prettier.io/blog/2022/03/16/2.6.0.html
2022-03-20 10:36:11 +01:00
"funding": [
{
"type": "opencollective",
"url": "https://opencollective.com/postcss/"
},
{
"type": "tidelift",
"url": "https://tidelift.com/funding/github/npm/autoprefixer"
Update npm packages
2023-08-19 09:08:11 +02:00
},
{
"type": "github",
"url": "https://github.com/sponsors/ai"
Update npm packages Note that the Prettier update made it possible to move a couple of comments after `default:`-cases back to their original/intended positions, please see https://prettier.io/blog/2022/03/16/2.6.0.html
2022-03-20 10:36:11 +01:00
}
],
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update npm packages
2024-03-17 13:50:21 +01:00
"browserslist": "^4.23.0",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"caniuse-lite": "^1.0.30001599",
Update npm packages
2024-01-20 09:40:33 +01:00
"fraction.js": "^4.3.7",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"normalize-range": "^0.1.2",
"picocolors": "^1.0.0",
Update npm packages
2022-01-09 10:05:52 +01:00
"postcss-value-parser": "^4.2.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"bin": {
"autoprefixer": "bin/autoprefixer"
},
"engines": {
"node": "^10 || ^12 || >=14"
},
"peerDependencies": {
"postcss": "^8.1.0"
}
},
Update npm packages
2023-01-15 10:34:56 +01:00
"node_modules/available-typed-arrays": {
"version": "1.0.5",
"resolved": "https://registry.npmjs.org/available-typed-arrays/-/available-typed-arrays-1.0.5.tgz",
"integrity": "sha512-DMD0KiN46eipeziST1LPP/STfDU0sufISXmjSgvVsoU2tqxctQeASejWcfNtxYKqETM1UxQ8sp2OrSBWpHY6sw==",
"dev": true,
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/axios": {
"version": "1.6.2",
"resolved": "https://registry.npmjs.org/axios/-/axios-1.6.2.tgz",
"integrity": "sha512-7i24Ri4pmDRfJTR7LDBhsOTtcm+9kjX5WiY1X3wIisx6G9So3pfMkEiU7emUBe46oceVImccTEM3k6C5dbVW8A==",
"dev": true,
"dependencies": {
"follow-redirects": "^1.15.0",
"form-data": "^4.0.0",
"proxy-from-env": "^1.1.0"
}
},
Update npm packages
2023-06-25 09:18:41 +02:00
"node_modules/b4a": {
Update dependencies to the most recent versions
2024-02-10 18:02:15 +01:00
"version": "1.6.6",
"resolved": "https://registry.npmjs.org/b4a/-/b4a-1.6.6.tgz",
"integrity": "sha512-5Tk1HLk6b6ctmjIkAcU/Ujv/1WqiDl0F0JdRCR80VsOcUlHcu7pWeWRlOqQLHfDEsVx9YH/aif5AG4ehoCtTmg==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "Apache-2.0"
Update npm packages
2023-06-25 09:18:41 +02:00
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/babel-loader": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"version": "9.1.3",
"resolved": "https://registry.npmjs.org/babel-loader/-/babel-loader-9.1.3.tgz",
"integrity": "sha512-xG3ST4DglodGf8qSwv0MdeWLhrDsw/32QMdTO5T1ZIp9gQur0HkCyFs7Awskr10JKXFXwpAhiCuYX5oGXnRGbw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"find-cache-dir": "^4.0.0",
Update npm packages
2022-10-29 10:17:36 +02:00
"schema-utils": "^4.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update npm packages
2022-10-29 10:17:36 +02:00
"node": ">= 14.15.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependencies": {
Update npm packages
2022-10-29 10:17:36 +02:00
"@babel/core": "^7.12.0",
"webpack": ">=5"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/babel-plugin-polyfill-corejs2": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "0.4.10",
"resolved": "https://registry.npmjs.org/babel-plugin-polyfill-corejs2/-/babel-plugin-polyfill-corejs2-0.4.10.tgz",
"integrity": "sha512-rpIuu//y5OX6jVU+a5BCn1R5RSZYWAl2Nar76iwaOdycqb6JPxediskWFMMl7stfwNJR4b7eiQvh5fB5TEQJTQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"@babel/compat-data": "^7.22.6",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@babel/helper-define-polyfill-provider": "^0.6.1",
Update npm packages
2023-08-19 09:08:11 +02:00
"semver": "^6.3.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependencies": {
Update npm packages
2023-08-19 09:08:11 +02:00
"@babel/core": "^7.4.0 || ^8.0.0-0 <8.0.0"
}
},
"node_modules/babel-plugin-polyfill-corejs2/node_modules/semver": {
"version": "6.3.1",
"resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz",
"integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==",
"dev": true,
"bin": {
"semver": "bin/semver.js"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/babel-plugin-polyfill-corejs3": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "0.10.4",
"resolved": "https://registry.npmjs.org/babel-plugin-polyfill-corejs3/-/babel-plugin-polyfill-corejs3-0.10.4.tgz",
"integrity": "sha512-25J6I8NGfa5YkCDogHRID3fVCadIR8/pGl1/spvCkzb6lVn6SR3ojpx9nOn9iEBcUsjY24AmdKm5khcfKdylcg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@babel/helper-define-polyfill-provider": "^0.6.1",
"core-js-compat": "^3.36.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependencies": {
Update npm packages
2023-08-19 09:08:11 +02:00
"@babel/core": "^7.4.0 || ^8.0.0-0 <8.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/babel-plugin-polyfill-regenerator": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "0.6.1",
"resolved": "https://registry.npmjs.org/babel-plugin-polyfill-regenerator/-/babel-plugin-polyfill-regenerator-0.6.1.tgz",
"integrity": "sha512-JfTApdE++cgcTWjsiCQlLyFBMbTUft9ja17saCc93lgV33h4tuCVj7tlvu//qpLwaG+3yEz7/KhahGrUMkVq9g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@babel/helper-define-polyfill-provider": "^0.6.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependencies": {
Update npm packages
2023-08-19 09:08:11 +02:00
"@babel/core": "^7.4.0 || ^8.0.0-0 <8.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/bach": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/bach/-/bach-2.0.1.tgz",
"integrity": "sha512-A7bvGMGiTOxGMpNupYl9HQTf0FFDNF4VCmks4PJpFyN1AX2pdKuxuwdvUz2Hu388wcgp+OvGFNsumBfFNkR7eg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"async-done": "^2.0.0",
"async-settle": "^2.0.0",
"now-and-later": "^3.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/balanced-match": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.0.tgz",
"integrity": "sha1-ibTRmasr7kneFk6gK4nORi1xt2c=",
"dev": true
},
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"node_modules/bare-events": {
Update puppeteer to 22.6.0
2024-03-23 16:22:51 +01:00
"version": "2.2.2",
"resolved": "https://registry.npmjs.org/bare-events/-/bare-events-2.2.2.tgz",
"integrity": "sha512-h7z00dWdG0PYOQEvChhOSWvOfkIKsdZGkWr083FgN/HyoQuebSew/cgirYqh9SCuy/hRvxc5Vy6Fw8xAmYHLkQ==",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"dev": true,
"optional": true
},
"node_modules/bare-fs": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "2.3.1",
"resolved": "https://registry.npmjs.org/bare-fs/-/bare-fs-2.3.1.tgz",
"integrity": "sha512-W/Hfxc/6VehXlsgFtbB5B4xFcsCl+pAh30cYhoFyXErf6oGrwjh8SwiPAdHgpmWonKuYpZgGywN0SXt7dgsADA==",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "Apache-2.0",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"optional": true,
"dependencies": {
"bare-events": "^2.0.0",
"bare-path": "^2.0.0",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"bare-stream": "^2.0.0"
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
}
},
"node_modules/bare-os": {
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"version": "2.4.0",
"resolved": "https://registry.npmjs.org/bare-os/-/bare-os-2.4.0.tgz",
"integrity": "sha512-v8DTT08AS/G0F9xrhyLtepoo9EJBJ85FRSMbu1pQUlAf6A8T0tEEQGMVObWeqpjhSPXsE0VGlluFBJu2fdoTNg==",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "Apache-2.0",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"optional": true
},
"node_modules/bare-path": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"version": "2.1.3",
"resolved": "https://registry.npmjs.org/bare-path/-/bare-path-2.1.3.tgz",
"integrity": "sha512-lh/eITfU8hrj9Ru5quUp0Io1kJWIk1bTjzo7JH1P5dWmQ2EL4hFUlfI8FonAhSlgIfhn63p84CDY/x+PisgcXA==",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "Apache-2.0",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"optional": true,
"dependencies": {
"bare-os": "^2.1.0"
}
},
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"node_modules/bare-stream": {
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"version": "2.1.3",
"resolved": "https://registry.npmjs.org/bare-stream/-/bare-stream-2.1.3.tgz",
"integrity": "sha512-tiDAH9H/kP+tvNO5sczyn9ZAA7utrSMobyDchsnyyXBuUe2FSQWbxhtuHB8jwpHYYevVo2UJpcmvvjrbHboUUQ==",
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "Apache-2.0",
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"optional": true,
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"streamx": "^2.18.0"
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/base64-js": {
"version": "1.5.1",
"resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.5.1.tgz",
"integrity": "sha512-AKpaYlHn8t4SVbOHCy+b5+KKgvR4vrsD8vbvrbiQJps7fKDTkjkDry6ji0rUJjC0kzbNePLwzxq8iypo41qeWA==",
"dev": true,
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/feross"
},
{
"type": "patreon",
"url": "https://www.patreon.com/feross"
},
{
"type": "consulting",
"url": "https://feross.org/support"
}
]
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/basic-ftp": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "5.0.5",
"resolved": "https://registry.npmjs.org/basic-ftp/-/basic-ftp-5.0.5.tgz",
"integrity": "sha512-4Bcg1P8xhUuqcii/S0Z9wiHIrQVPMermM1any+MX5GeGD7faD3/msQUDGLol9wOcz4/jbg/WJnGqoJF6LiBdtg==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"engines": {
"node": ">=10.0.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/binaryextensions": {
"version": "2.3.0",
"resolved": "https://registry.npmjs.org/binaryextensions/-/binaryextensions-2.3.0.tgz",
"integrity": "sha512-nAihlQsYGyc5Bwq6+EsubvANYGExeJKHDO3RjnvwU042fawQTQfM3Kxn7IHUXQOz4bzfwsGYYHGSvXyW4zOGLg==",
"dev": true,
"engines": {
"node": ">=0.8"
},
"funding": {
"url": "https://bevry.me/fund"
}
},
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"node_modules/bindings": {
"version": "1.5.0",
"resolved": "https://registry.npmjs.org/bindings/-/bindings-1.5.0.tgz",
"integrity": "sha512-p2q/t/mhvuOj/UeLlV6566GD/guowlr0hHxClI0W9m7MWYkL1F0hLo+0Aexs9HSPCtR1SXQ0TD3MMKrXZajbiQ==",
"dev": true,
"dependencies": {
"file-uri-to-path": "1.0.0"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/bl": {
"version": "4.1.0",
"resolved": "https://registry.npmjs.org/bl/-/bl-4.1.0.tgz",
"integrity": "sha512-1W07cM9gS6DcLperZfFSj+bWLtaPGSOHWhPiGzXmvVJbRLdG82sH/Kn8EtW1VqWVA54AKf2h5k5BbnIbwF3h6w==",
"dev": true,
"dependencies": {
"buffer": "^5.5.0",
"inherits": "^2.0.4",
"readable-stream": "^3.4.0"
}
},
"node_modules/bl/node_modules/readable-stream": {
"version": "3.6.2",
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.2.tgz",
"integrity": "sha512-9u/sniCrY3D5WdsERHzHE4G2YCXqoG5FTHUiCC4SIbr6XcLZBY05ya9EKjYek9O5xOAwjGq+1JdGBAS7Q9ScoA==",
"dev": true,
"dependencies": {
"inherits": "^2.0.3",
"string_decoder": "^1.1.1",
"util-deprecate": "^1.0.1"
},
"engines": {
"node": ">= 6"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/bluebird": {
"version": "3.7.2",
"resolved": "https://registry.npmjs.org/bluebird/-/bluebird-3.7.2.tgz",
"integrity": "sha512-XpNj6GDQzdfW+r2Wnn7xiSAd7TM3jzkxGXBGTtWKuSXv1xUV+azxAm8jdWZN06QTQk+2N2XB9jRDkvbmQmcRtg==",
"dev": true
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/boolbase": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/boolbase/-/boolbase-1.0.0.tgz",
"integrity": "sha512-JZOSA7Mo9sNGB8+UjSgzdLtokWAky1zbztM3WRLCbZ70/3cTANmQmOdR7y2g+J0e2WXywy1yS468tY+IruqEww==",
"dev": true,
"license": "ISC"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/brace-expansion": {
"version": "1.1.11",
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz",
"integrity": "sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==",
"dev": true,
"dependencies": {
"balanced-match": "^1.0.0",
"concat-map": "0.0.1"
}
},
"node_modules/browserslist": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "4.23.2",
"resolved": "https://registry.npmjs.org/browserslist/-/browserslist-4.23.2.tgz",
"integrity": "sha512-qkqSyistMYdxAcw+CzbZwlBy8AGmS/eEWs+sEV5TnLRGDOL+C5M2EnH6tlZyg0YoAxGJAFKh61En9BR941GnHA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update npm packages Note that the Prettier update made it possible to move a couple of comments after `default:`-cases back to their original/intended positions, please see https://prettier.io/blog/2022/03/16/2.6.0.html
2022-03-20 10:36:11 +01:00
"funding": [
{
"type": "opencollective",
"url": "https://opencollective.com/browserslist"
},
{
"type": "tidelift",
"url": "https://tidelift.com/funding/github/npm/browserslist"
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
},
{
"type": "github",
"url": "https://github.com/sponsors/ai"
Update npm packages Note that the Prettier update made it possible to move a couple of comments after `default:`-cases back to their original/intended positions, please see https://prettier.io/blog/2022/03/16/2.6.0.html
2022-03-20 10:36:11 +01:00
}
],
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"caniuse-lite": "^1.0.30001640",
"electron-to-chromium": "^1.4.820",
Update npm packages
2023-12-23 12:29:51 +01:00
"node-releases": "^2.0.14",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"update-browserslist-db": "^1.1.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"bin": {
"browserslist": "cli.js"
},
"engines": {
"node": "^6 || ^7 || ^8 || ^9 || ^10 || ^11 || ^12 || >=13.7"
}
},
"node_modules/buffer": {
"version": "5.7.1",
"resolved": "https://registry.npmjs.org/buffer/-/buffer-5.7.1.tgz",
"integrity": "sha512-EHcyIPBQ4BSGlvjB16k5KgAJ27CIsHY/2JBmCRReo48y9rQ3MaUzWX3KVlBa4U7MyX02HdVj0K7C3WaB3ju7FQ==",
"dev": true,
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/feross"
},
{
"type": "patreon",
"url": "https://www.patreon.com/feross"
},
{
"type": "consulting",
"url": "https://feross.org/support"
}
],
"dependencies": {
"base64-js": "^1.3.1",
"ieee754": "^1.1.13"
}
},
"node_modules/buffer-crc32": {
"version": "0.2.13",
"resolved": "https://registry.npmjs.org/buffer-crc32/-/buffer-crc32-0.2.13.tgz",
"integrity": "sha1-DTM+PwDqxQqhRUq9MO+MKl2ackI=",
"dev": true,
"engines": {
"node": "*"
}
},
"node_modules/buffer-from": {
"version": "1.1.1",
"resolved": "https://registry.npmjs.org/buffer-from/-/buffer-from-1.1.1.tgz",
"integrity": "sha512-MQcXEUbCKtEo7bhqEs6560Hyd4XaovZlO/k9V3hjVUF/zwW7KBVdSK4gIt/bzwS9MbR5qob+F5jusZsb0YQK2A==",
"dev": true
},
[api-minor] Move to Fluent for the localization (bug 1858715) - For the generic viewer we use @fluent/dom and @fluent/bundle - For the builtin pdf viewer in Firefox, we set a localization url and then we rely on document.l10n which is a DOMLocalization object.
2023-10-13 16:23:17 +02:00
"node_modules/cached-iterable": {
"version": "0.3.0",
"resolved": "https://registry.npmjs.org/cached-iterable/-/cached-iterable-0.3.0.tgz",
"integrity": "sha512-MDqM6TpBVebZD4UDtmlFp8EjVtRcsB6xt9aRdWymjk0fWVUUGgmt/V7o0H0gkI2Tkvv8B0ucjidZm4mLosdlWw==",
"dev": true,
"engines": {
"node": ">=8.9.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/call-bind": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/call-bind/-/call-bind-1.0.2.tgz",
"integrity": "sha512-7O+FbCihrB5WGbFYesctwmTKae6rOiIzmz1icreWJ+0aA7LJfuqhEso2T9ncpcFtzMQtzXf2QGGueWJGTYsqrA==",
"dev": true,
"dependencies": {
"function-bind": "^1.1.1",
"get-intrinsic": "^1.0.2"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/callsites": {
"version": "3.1.0",
"resolved": "https://registry.npmjs.org/callsites/-/callsites-3.1.0.tgz",
"integrity": "sha512-P8BjAsXvZS+VIDUI11hHCQEv74YT67YUi5JJFNWIqL235sBmjX4+qx9Muvls5ivyNENctx46xQLQ3aTuE7ssaQ==",
"dev": true,
"engines": {
"node": ">=6"
}
},
"node_modules/caniuse-lite": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "1.0.30001641",
"resolved": "https://registry.npmjs.org/caniuse-lite/-/caniuse-lite-1.0.30001641.tgz",
"integrity": "sha512-Phv5thgl67bHYo1TtMY/MurjkHhV4EDaCosezRXgZ8jzA/Ub+wjxAvbGvjoFENStinwi5kCyOYV3mi5tOGykwA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update npm packages Note that the Prettier update made it possible to move a couple of comments after `default:`-cases back to their original/intended positions, please see https://prettier.io/blog/2022/03/16/2.6.0.html
2022-03-20 10:36:11 +01:00
"funding": [
{
"type": "opencollective",
"url": "https://opencollective.com/browserslist"
},
{
"type": "tidelift",
"url": "https://tidelift.com/funding/github/npm/caniuse-lite"
Update npm packages
2023-04-15 22:08:58 +02:00
},
{
"type": "github",
"url": "https://github.com/sponsors/ai"
Update npm packages Note that the Prettier update made it possible to move a couple of comments after `default:`-cases back to their original/intended positions, please see https://prettier.io/blog/2022/03/16/2.6.0.html
2022-03-20 10:36:11 +01:00
}
Update dependencies to the most recent versions
2024-05-23 15:59:27 +02:00
],
"license": "CC-BY-4.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"node_modules/canvas": {
Update npm packages
2023-04-15 22:08:58 +02:00
"version": "2.11.2",
"resolved": "https://registry.npmjs.org/canvas/-/canvas-2.11.2.tgz",
"integrity": "sha512-ItanGBMrmRV7Py2Z+Xhs7cT+FNt5K0vPL4p9EZ/UX/Mu7hFbkxSjKF2KVtPwX7UYWp7dRKnrTvReflgrItJbdw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"hasInstallScript": true,
"dependencies": {
"@mapbox/node-pre-gyp": "^1.0.0",
Update npm packages
2022-11-13 21:28:21 +01:00
"nan": "^2.17.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"simple-get": "^3.0.3"
},
"engines": {
"node": ">=6"
}
},
"node_modules/catharsis": {
"version": "0.9.0",
"resolved": "https://registry.npmjs.org/catharsis/-/catharsis-0.9.0.tgz",
"integrity": "sha512-prMTQVpcns/tzFgFVkVp6ak6RykZyWb3gu8ckUpd6YkTlacOd3DXGJjIpD4Q6zJirizvaiAjSSHlOsA+6sNh2A==",
"dev": true,
"dependencies": {
"lodash": "^4.17.15"
},
"engines": {
"node": ">= 10"
}
},
"node_modules/cephes": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/cephes/-/cephes-1.2.0.tgz",
"integrity": "sha512-twuUuJRrIrsELHz6foJtZlqrz6FC36zoHZJvvThsrM1UWPKxyoilw1Rka6Hk0AmPFKHKUoGwGfAtvNZNtNZu0g==",
"dev": true
},
"node_modules/chalk": {
Update npm packages
2023-08-19 09:08:11 +02:00
"version": "2.4.2",
"resolved": "https://registry.npmjs.org/chalk/-/chalk-2.4.2.tgz",
"integrity": "sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"ansi-styles": "^3.2.1",
"escape-string-regexp": "^1.0.5",
"supports-color": "^5.3.0"
},
"engines": {
"node": ">=4"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/cheerio": {
"version": "1.0.0-rc.12",
"resolved": "https://registry.npmjs.org/cheerio/-/cheerio-1.0.0-rc.12.tgz",
"integrity": "sha512-VqR8m68vM46BNnuZ5NtnGBKIE/DfN0cRIzg9n40EIq9NOv90ayxLBXA8fXC5gquFRGJSTRqBq25Jt2ECLR431Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"cheerio-select": "^2.1.0",
"dom-serializer": "^2.0.0",
"domhandler": "^5.0.3",
"domutils": "^3.0.1",
"htmlparser2": "^8.0.1",
"parse5": "^7.0.0",
"parse5-htmlparser2-tree-adapter": "^7.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"engines": {
"node": ">= 6"
},
"funding": {
"url": "https://github.com/cheeriojs/cheerio?sponsor=1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/cheerio-select": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/cheerio-select/-/cheerio-select-2.1.0.tgz",
"integrity": "sha512-9v9kG0LvzrlcungtnJtpGNxY+fzECQKhK4EGJX2vByejiMX84MFNQw4UxPJl3bFbTMw+Dfs37XaIkCwTZfLh4g==",
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "BSD-2-Clause",
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"boolbase": "^1.0.0",
"css-select": "^5.1.0",
"css-what": "^6.1.0",
"domelementtype": "^2.3.0",
"domhandler": "^5.0.3",
"domutils": "^3.0.1"
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"funding": {
"url": "https://github.com/sponsors/fb55"
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/cheerio/node_modules/entities": {
"version": "4.5.0",
"resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz",
"integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "BSD-2-Clause",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=0.12"
},
"funding": {
"url": "https://github.com/fb55/entities?sponsor=1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/cheerio/node_modules/htmlparser2": {
"version": "8.0.2",
"resolved": "https://registry.npmjs.org/htmlparser2/-/htmlparser2-8.0.2.tgz",
"integrity": "sha512-GYdjWKDkbRLkZ5geuHs5NY1puJ+PXwP7+fHPRz06Eirsb9ugf6d8kkXav6ADhcODhFFPMIXyxkxSuMf3D6NCFA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"funding": [
"https://github.com/fb55/htmlparser2?sponsor=1",
{
"type": "github",
"url": "https://github.com/sponsors/fb55"
}
],
"license": "MIT",
"dependencies": {
"domelementtype": "^2.3.0",
"domhandler": "^5.0.3",
"domutils": "^3.0.1",
"entities": "^4.4.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/chownr": {
"version": "1.1.4",
"resolved": "https://registry.npmjs.org/chownr/-/chownr-1.1.4.tgz",
"integrity": "sha512-jJ0bqzaylmJtVnNgzTeSOs8DPavpbYgEr/b0YL8/2GO3xJEhInFmhKMUnEJQjZumK7KXGFhUy89PrsJWlakBVg==",
"dev": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/chrome-trace-event": {
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/chrome-trace-event/-/chrome-trace-event-1.0.3.tgz",
"integrity": "sha512-p3KULyQg4S7NIHixdwbGX+nFHkoBiA4YQmyWtjb8XngSKV124nJmRysgAeujbUVb15vh+RvFUfCPqU7rXk+hZg==",
"dev": true,
"engines": {
"node": ">=6.0"
}
},
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"node_modules/chromium-bidi": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "0.6.0",
"resolved": "https://registry.npmjs.org/chromium-bidi/-/chromium-bidi-0.6.0.tgz",
"integrity": "sha512-VnxVrpGojAjkiGFN2I+KtsDILFAjiGWVEDizOEnKzEDkT93eQT1cqTfUkqmOyLq33i1q4a1KDYbH+52CUe4Ufw==",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "Apache-2.0",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dependencies": {
Update Puppeteer to the latest version This also required updating the `postinstall`-step to account for recent changes in Puppeteer.
2023-09-25 11:56:02 +02:00
"mitt": "3.0.1",
Update npm packages
2024-03-17 13:50:21 +01:00
"urlpattern-polyfill": "10.0.0",
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"zod": "3.23.8"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
},
"peerDependencies": {
"devtools-protocol": "*"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/ci-info": {
Update npm packages
2023-12-23 12:29:51 +01:00
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/ci-info/-/ci-info-4.0.0.tgz",
"integrity": "sha512-TdHqgGf9odd8SXNuxtUBVx8Nv+qZOejE6qyqiy5NtbYYQOeFa6zmHkxlPzmaLxWWHsU6nJmB7AETdVPi+2NBUg==",
Update npm packages
2022-11-27 10:18:30 +01:00
"dev": true,
Update npm packages
2023-05-14 10:12:06 +02:00
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/sibiraj-s"
}
],
Update npm packages
2022-11-27 10:18:30 +01:00
"engines": {
"node": ">=8"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/clean-regexp": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/clean-regexp/-/clean-regexp-1.0.0.tgz",
"integrity": "sha1-jffHquUf02h06PjQW5GAvBGj/tc=",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"escape-string-regexp": "^1.0.5"
},
"engines": {
"node": ">=4"
}
},
"node_modules/clone": {
"version": "2.1.2",
"resolved": "https://registry.npmjs.org/clone/-/clone-2.1.2.tgz",
"integrity": "sha1-G39Ln1kfHo+DZwQBYANFoCiHQ18=",
"dev": true,
"engines": {
"node": ">=0.8"
}
},
"node_modules/clone-buffer": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/clone-buffer/-/clone-buffer-1.0.0.tgz",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"integrity": "sha512-KLLTJWrvwIP+OPfMn0x2PheDEP20RPUcGXj/ERegTgdmPEZylALQldygiqrPPu8P45uNuPs7ckmReLY6v/iA5g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">= 0.10"
}
},
"node_modules/clone-stats": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/clone-stats/-/clone-stats-1.0.0.tgz",
"integrity": "sha1-s3gt/4u1R04Yuba/D9/ngvh3doA=",
"dev": true
},
"node_modules/cloneable-readable": {
"version": "1.1.3",
"resolved": "https://registry.npmjs.org/cloneable-readable/-/cloneable-readable-1.1.3.tgz",
"integrity": "sha512-2EF8zTQOxYq70Y4XKtorQupqF0m49MBz2/yf5Bj+MHjvpG3Hy7sImifnqD6UA+TKYxeSV+u6qqQPawN5UvnpKQ==",
"dev": true,
"dependencies": {
"inherits": "^2.0.1",
"process-nextick-args": "^2.0.0",
"readable-stream": "^2.3.5"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/cmake-js": {
"version": "7.2.1",
"resolved": "https://registry.npmjs.org/cmake-js/-/cmake-js-7.2.1.tgz",
"integrity": "sha512-AdPSz9cSIJWdKvm0aJgVu3X8i0U3mNTswJkSHzZISqmYVjZk7Td4oDFg0mCBA383wO+9pG5Ix7pEP1CZH9x2BA==",
"dev": true,
"dependencies": {
"axios": "^1.3.2",
"debug": "^4",
"fs-extra": "^10.1.0",
"lodash.isplainobject": "^4.0.6",
"memory-stream": "^1.0.0",
"node-api-headers": "^0.0.2",
"npmlog": "^6.0.2",
"rc": "^1.2.7",
"semver": "^7.3.8",
"tar": "^6.1.11",
"url-join": "^4.0.1",
"which": "^2.0.2",
"yargs": "^17.6.0"
},
"bin": {
"cmake-js": "bin/cmake-js"
},
"engines": {
"node": ">= 14.15.0"
}
},
"node_modules/cmake-js/node_modules/ansi-regex": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
"integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/cmake-js/node_modules/are-we-there-yet": {
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/are-we-there-yet/-/are-we-there-yet-3.0.1.tgz",
"integrity": "sha512-QZW4EDmGwlYur0Yyf/b2uGucHQMa8aFUP7eu9ddR73vvhFyt4V0Vl3QHPcTNJ8l6qYOBdxgXdnBXQrHilfRQBg==",
"dev": true,
"dependencies": {
"delegates": "^1.0.0",
"readable-stream": "^3.6.0"
},
"engines": {
"node": "^12.13.0 || ^14.15.0 || >=16.0.0"
}
},
"node_modules/cmake-js/node_modules/fs-extra": {
"version": "10.1.0",
"resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-10.1.0.tgz",
"integrity": "sha512-oRXApq54ETRj4eMiFzGnHWGy+zo5raudjuxN0b8H7s/RU2oW0Wvsx9O0ACRN/kRq9E8Vu/ReskGB5o3ji+FzHQ==",
"dev": true,
"dependencies": {
"graceful-fs": "^4.2.0",
"jsonfile": "^6.0.1",
"universalify": "^2.0.0"
},
"engines": {
"node": ">=12"
}
},
"node_modules/cmake-js/node_modules/gauge": {
"version": "4.0.4",
"resolved": "https://registry.npmjs.org/gauge/-/gauge-4.0.4.tgz",
"integrity": "sha512-f9m+BEN5jkg6a0fZjleidjN51VE1X+mPFQ2DJ0uv1V39oCLCbsGe6yjbBnp7eK7z/+GAon99a3nHuqbuuthyPg==",
"dev": true,
"dependencies": {
"aproba": "^1.0.3 || ^2.0.0",
"color-support": "^1.1.3",
"console-control-strings": "^1.1.0",
"has-unicode": "^2.0.1",
"signal-exit": "^3.0.7",
"string-width": "^4.2.3",
"strip-ansi": "^6.0.1",
"wide-align": "^1.1.5"
},
"engines": {
"node": "^12.13.0 || ^14.15.0 || >=16.0.0"
}
},
"node_modules/cmake-js/node_modules/is-fullwidth-code-point": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
"integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/cmake-js/node_modules/npmlog": {
"version": "6.0.2",
"resolved": "https://registry.npmjs.org/npmlog/-/npmlog-6.0.2.tgz",
"integrity": "sha512-/vBvz5Jfr9dT/aFWd0FIRf+T/Q2WBsLENygUaFUqstqsycmZAP/t5BvFJTK0viFmSUxiUKTUplWy5vt+rvKIxg==",
"dev": true,
"dependencies": {
"are-we-there-yet": "^3.0.0",
"console-control-strings": "^1.1.0",
"gauge": "^4.0.3",
"set-blocking": "^2.0.0"
},
"engines": {
"node": "^12.13.0 || ^14.15.0 || >=16.0.0"
}
},
"node_modules/cmake-js/node_modules/readable-stream": {
"version": "3.6.2",
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.2.tgz",
"integrity": "sha512-9u/sniCrY3D5WdsERHzHE4G2YCXqoG5FTHUiCC4SIbr6XcLZBY05ya9EKjYek9O5xOAwjGq+1JdGBAS7Q9ScoA==",
"dev": true,
"dependencies": {
"inherits": "^2.0.3",
"string_decoder": "^1.1.1",
"util-deprecate": "^1.0.1"
},
"engines": {
"node": ">= 6"
}
},
"node_modules/cmake-js/node_modules/semver": {
"version": "7.5.4",
"resolved": "https://registry.npmjs.org/semver/-/semver-7.5.4.tgz",
"integrity": "sha512-1bCSESV6Pv+i21Hvpxp3Dx+pSD8lIPt8uVjRrxAUt/nbswYc+tK6Y2btiULjd4+fnq15PX+nqQDC7Oft7WkwcA==",
"dev": true,
"dependencies": {
"lru-cache": "^6.0.0"
},
"bin": {
"semver": "bin/semver.js"
},
"engines": {
"node": ">=10"
}
},
"node_modules/cmake-js/node_modules/string-width": {
"version": "4.2.3",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
"integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
"dev": true,
"dependencies": {
"emoji-regex": "^8.0.0",
"is-fullwidth-code-point": "^3.0.0",
"strip-ansi": "^6.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/cmake-js/node_modules/strip-ansi": {
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
"integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
"dev": true,
"dependencies": {
"ansi-regex": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/cmake-js/node_modules/which": {
"version": "2.0.2",
"resolved": "https://registry.npmjs.org/which/-/which-2.0.2.tgz",
"integrity": "sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==",
"dev": true,
"dependencies": {
"isexe": "^2.0.0"
},
"bin": {
"node-which": "bin/node-which"
},
"engines": {
"node": ">= 8"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/co": {
"version": "3.1.0",
"resolved": "https://registry.npmjs.org/co/-/co-3.1.0.tgz",
"integrity": "sha512-CQsjCRiNObI8AtTsNIBDRMQ4oMR83CzEswHYahClvul7gKk+lDQiOKv+5qh7LQWf5sh6jkZNispz/QlsZxyNgA==",
"dev": true,
"license": "MIT"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/code-point-at": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/code-point-at/-/code-point-at-1.1.0.tgz",
"integrity": "sha1-DQcLTQQ6W+ozovGkDi7bPZpMz3c=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/color-convert": {
"version": "1.9.1",
"resolved": "https://registry.npmjs.org/color-convert/-/color-convert-1.9.1.tgz",
"integrity": "sha512-mjGanIiwQJskCC18rPR6OmrZ6fm2Lc7PeGFYwCmy5J34wC6F1PzdGL6xeMfmgicfYcNLGuVFA3WzXtIDCQSZxQ==",
"dev": true,
"dependencies": {
"color-name": "^1.1.1"
}
},
"node_modules/color-name": {
Update npm packages
2021-12-26 11:09:29 +01:00
"version": "1.1.4",
"resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz",
"integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
"node_modules/color-support": {
"version": "1.1.3",
"resolved": "https://registry.npmjs.org/color-support/-/color-support-1.1.3.tgz",
"integrity": "sha512-qiBjkpbMLO/HL68y+lh4q0/O1MZFj2RX6X/KmMa3+gJD3z+WwI1ZzDHysvqHGS3mP6mznPckpXmw1nI9cJjyRg==",
"dev": true,
"bin": {
"color-support": "bin.js"
}
},
Update npm packages
2021-12-26 11:09:29 +01:00
"node_modules/colord": {
Update npm packages
2022-09-04 09:57:59 +02:00
"version": "2.9.3",
"resolved": "https://registry.npmjs.org/colord/-/colord-2.9.3.tgz",
"integrity": "sha512-jeC1axXpnb0/2nn/Y1LPuLdgXBLH7aDcHu4KEKfqw3CUhX7ZpfBSlPKyqXE6btIgEzfWtrX3/tyBCaCvXvMkOw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/combined-stream": {
"version": "1.0.8",
"resolved": "https://registry.npmjs.org/combined-stream/-/combined-stream-1.0.8.tgz",
"integrity": "sha512-FQN4MRfuJeHf7cBbBMJFXhKSDq+2kAArBlmRBvcvFE5BB1HZKXtSFASDhdlz9zOYwxh8lDdnvmMOe/+5cdoEdg==",
"dev": true,
"dependencies": {
"delayed-stream": "~1.0.0"
},
"engines": {
"node": ">= 0.8"
}
},
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node_modules/common-path-prefix": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/common-path-prefix/-/common-path-prefix-3.0.0.tgz",
"integrity": "sha512-QE33hToZseCH3jS0qN96O/bSh3kaw/h+Tq7ngyY9eWDUnTlTNUyqfqvCXioLe5Na5jFsL78ra/wuBU4iuEgd4w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
"node_modules/concat-map": {
"version": "0.0.1",
"resolved": "https://registry.npmjs.org/concat-map/-/concat-map-0.0.1.tgz",
"integrity": "sha1-2Klr13/Wjfd5OnMDajug1UBdR3s=",
"dev": true
},
"node_modules/console-control-strings": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/console-control-strings/-/console-control-strings-1.1.0.tgz",
"integrity": "sha1-PXz0Rk22RG6mRL9LOVB/mFEAjo4=",
"dev": true
},
"node_modules/convert-source-map": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/convert-source-map/-/convert-source-map-2.0.0.tgz",
"integrity": "sha512-Kvp459HrV2FEJ1CAsi1Ku+MY3kasH19TFykTz2xWmMeq6bk2NU3XXvfJ+Q61m0xktWwt+1HSYf3JZsTms3aRJg==",
"dev": true,
"license": "MIT"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"node_modules/copy-props": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/copy-props/-/copy-props-4.0.0.tgz",
"integrity": "sha512-bVWtw1wQLzzKiYROtvNlbJgxgBYt2bMJpkCbKmXM3xyijvcjjWXEk5nyrrT3bgJ7ODb19ZohE2T0Y3FgNPyoTw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"each-props": "^3.0.0",
Bump copy-props from 2.0.4 to 2.0.5 Bumps [copy-props](https://github.com/gulpjs/copy-props) from 2.0.4 to 2.0.5. - [Release notes](https://github.com/gulpjs/copy-props/releases) - [Changelog](https://github.com/gulpjs/copy-props/blob/master/CHANGELOG.md) - [Commits](https://github.com/gulpjs/copy-props/compare/2.0.4...2.0.5) --- updated-dependencies: - dependency-name: copy-props dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
2022-01-27 21:37:54 +00:00
"is-plain-object": "^5.0.0"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
},
"engines": {
"node": ">= 10.13.0"
Bump copy-props from 2.0.4 to 2.0.5 Bumps [copy-props](https://github.com/gulpjs/copy-props) from 2.0.4 to 2.0.5. - [Release notes](https://github.com/gulpjs/copy-props/releases) - [Changelog](https://github.com/gulpjs/copy-props/blob/master/CHANGELOG.md) - [Commits](https://github.com/gulpjs/copy-props/compare/2.0.4...2.0.5) --- updated-dependencies: - dependency-name: copy-props dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
2022-01-27 21:37:54 +00:00
}
},
"node_modules/copy-props/node_modules/is-plain-object": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/is-plain-object/-/is-plain-object-5.0.0.tgz",
"integrity": "sha512-VRSzKkbMm5jMDoKLbltAkFQ5Qr7VDiTFGXxYFXXowVj387GeGNOCsOH6Msy00SGZ3Fp84b1Naa1psqgcCIEP5Q==",
"dev": true,
"engines": {
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/core-js": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"version": "3.37.1",
"resolved": "https://registry.npmjs.org/core-js/-/core-js-3.37.1.tgz",
"integrity": "sha512-Xn6qmxrQZyB0FFY8E3bgRXei3lWDJHhvI+u0q9TKIYM49G8pAr0FgnnrFRAmsbptZL1yxRADVXn+x5AGsbBfyw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"hasInstallScript": true,
"funding": {
"type": "opencollective",
"url": "https://opencollective.com/core-js"
}
},
"node_modules/core-js-compat": {
Upgrade `eslint-plugin-unicorn` to version 53.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v53.0.0 doesn't indicate any breaking changes that should impact us. Most notably it contains support for ESLint 9, which brings us a step closer towards #17928.
2024-05-14 16:23:36 +02:00
"version": "3.37.1",
"resolved": "https://registry.npmjs.org/core-js-compat/-/core-js-compat-3.37.1.tgz",
"integrity": "sha512-9TNiImhKvQqSUkOvk/mMRZzOANTiEVC7WaBNhHcKM7x+/5E1l5NvsysR19zuDQScE8k+kfQXWRN3AtS/eOSHpg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"browserslist": "^4.23.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
"type": "opencollective",
"url": "https://opencollective.com/core-js"
}
},
"node_modules/core-util-is": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/core-util-is/-/core-util-is-1.0.2.tgz",
"integrity": "sha1-tf1UIgqivFq1eqtxQMlAdUUDwac=",
"dev": true
},
"node_modules/cosmiconfig": {
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"version": "9.0.0",
"resolved": "https://registry.npmjs.org/cosmiconfig/-/cosmiconfig-9.0.0.tgz",
"integrity": "sha512-itvL5h8RETACmOTFc4UfIyB2RfEHi71Ax6E/PivVxq9NseKbOWpeyHEOIbmAw1rs8Ak0VursQNww7lf7YtUwzg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"env-paths": "^2.2.1",
Update Puppeteer to version 21.2.1 This release fixes the upstream bug that caused old Firefox revisions to not be removed from the cache. Fixes #16904.
2023-09-16 14:02:41 +02:00
"import-fresh": "^3.3.0",
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"js-yaml": "^4.1.0",
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"parse-json": "^5.2.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"node": ">=14"
Update npm packages
2023-03-25 09:41:15 +01:00
},
"funding": {
"url": "https://github.com/sponsors/d-fischer"
Update Puppeteer to version 21.2.1 This release fixes the upstream bug that caused old Firefox revisions to not be removed from the cache. Fixes #16904.
2023-09-16 14:02:41 +02:00
},
"peerDependencies": {
"typescript": ">=4.9.5"
},
"peerDependenciesMeta": {
"typescript": {
"optional": true
}
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
}
},
"node_modules/cosmiconfig/node_modules/argparse": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
"integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
"dev": true
},
"node_modules/cosmiconfig/node_modules/js-yaml": {
"version": "4.1.0",
"resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz",
"integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==",
"dev": true,
"dependencies": {
"argparse": "^2.0.1"
},
"bin": {
"js-yaml": "bin/js-yaml.js"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/cosmiconfig/node_modules/parse-json": {
"version": "5.2.0",
"resolved": "https://registry.npmjs.org/parse-json/-/parse-json-5.2.0.tgz",
"integrity": "sha512-ayCKvm/phCGxOkYRSCM82iDwct8/EonSEgCSxWxD7ve6jHggsFl4fZVQBPRNgQoKiuV/odhFrGzQXZwbifC8Rg==",
"dev": true,
"dependencies": {
"@babel/code-frame": "^7.0.0",
"error-ex": "^1.3.1",
"json-parse-even-better-errors": "^2.3.0",
"lines-and-columns": "^1.1.6"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/cross-env": {
"version": "7.0.3",
"resolved": "https://registry.npmjs.org/cross-env/-/cross-env-7.0.3.tgz",
"integrity": "sha512-+/HKd6EgcQCJGh2PSjZuUitQBQynKor4wrFbRg4DtAgS1aWO+gU52xpH7M9ScGgXSYmAVS9bIJ8EzuaGw0oNAw==",
"dev": true,
"dependencies": {
"cross-spawn": "^7.0.1"
},
"bin": {
"cross-env": "src/bin/cross-env.js",
"cross-env-shell": "src/bin/cross-env-shell.js"
},
"engines": {
"node": ">=10.14",
"npm": ">=6",
"yarn": ">=1"
}
},
"node_modules/cross-spawn": {
"version": "7.0.3",
"resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.3.tgz",
"integrity": "sha512-iRDPJKUPVEND7dHPO8rkbOnPpyDygcDFtWjpeWNCgy8WP2rXcxXL8TskReQl6OrB2G7+UJrags1q15Fudc7G6w==",
"dev": true,
"dependencies": {
"path-key": "^3.1.0",
"shebang-command": "^2.0.0",
"which": "^2.0.1"
},
"engines": {
"node": ">= 8"
}
},
"node_modules/cross-spawn/node_modules/path-key": {
"version": "3.1.1",
"resolved": "https://registry.npmjs.org/path-key/-/path-key-3.1.1.tgz",
"integrity": "sha512-ojmeN0qd+y0jszEtoY48r0Peq5dwMEkIlCOu6Q5f41lfkswXuKtYrhgoTpLnyIcHm24Uhqx+5Tqm2InSwLhE6Q==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/cross-spawn/node_modules/shebang-command": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/shebang-command/-/shebang-command-2.0.0.tgz",
"integrity": "sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==",
"dev": true,
"dependencies": {
"shebang-regex": "^3.0.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/cross-spawn/node_modules/shebang-regex": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/shebang-regex/-/shebang-regex-3.0.0.tgz",
"integrity": "sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/cross-spawn/node_modules/which": {
"version": "2.0.2",
"resolved": "https://registry.npmjs.org/which/-/which-2.0.2.tgz",
"integrity": "sha512-BLI3Tl1TW3Pvl70l3yq3Y64i+awpwXqsGBYWkkqMtnbXgrMD+yj7rhW0kuEDxzJaYXGjEW5ogapKNMEKNMjibA==",
"dev": true,
"dependencies": {
"isexe": "^2.0.0"
},
"bin": {
"node-which": "bin/node-which"
},
"engines": {
"node": ">= 8"
}
},
Update npm packages
2022-02-20 10:08:23 +01:00
"node_modules/css-functions-list": {
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"version": "3.2.2",
"resolved": "https://registry.npmjs.org/css-functions-list/-/css-functions-list-3.2.2.tgz",
"integrity": "sha512-c+N0v6wbKVxTu5gOBBFkr9BEdBWaqqjQeiJ8QvSRIJOf+UxlJh930m8e6/WNeODIK0mYLFkoONrnj16i2EcvfQ==",
Update npm packages
2022-02-20 10:08:23 +01:00
"dev": true,
"engines": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"node": ">=12 || >=16"
Update npm packages
2022-02-20 10:08:23 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/css-select": {
"version": "5.1.0",
"resolved": "https://registry.npmjs.org/css-select/-/css-select-5.1.0.tgz",
"integrity": "sha512-nwoRF1rvRRnnCqqY7updORDsuqKzqYJ28+oSMaJMMgOauh3fvwHqMS7EZpIPqK8GL+g9mKxF1vP/ZjSeNjEVHg==",
"dev": true,
"license": "BSD-2-Clause",
"dependencies": {
"boolbase": "^1.0.0",
"css-what": "^6.1.0",
"domhandler": "^5.0.2",
"domutils": "^3.0.1",
"nth-check": "^2.0.1"
},
"funding": {
"url": "https://github.com/sponsors/fb55"
}
},
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"node_modules/css-tree": {
"version": "2.3.1",
"resolved": "https://registry.npmjs.org/css-tree/-/css-tree-2.3.1.tgz",
"integrity": "sha512-6Fv1DV/TYw//QF5IzQdqsNDjx/wc8TrMBZsqjL9eW01tWb7R7k/mq+/VXfJCl7SoD5emsJop9cOByJZfs8hYIw==",
"dev": true,
"dependencies": {
"mdn-data": "2.0.30",
"source-map-js": "^1.0.1"
},
"engines": {
"node": "^10 || ^12.20.0 || ^14.13.0 || >=15.0.0"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/css-what": {
"version": "6.1.0",
"resolved": "https://registry.npmjs.org/css-what/-/css-what-6.1.0.tgz",
"integrity": "sha512-HTUrgRJ7r4dsZKU6GjmpfRK1O76h97Z8MfS1G0FozR+oF2kG6Vfe8JE6zwrkbxigziPHinCJ+gCPjA9EaBDtRw==",
"dev": true,
"license": "BSD-2-Clause",
"engines": {
"node": ">= 6"
},
"funding": {
"url": "https://github.com/sponsors/fb55"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/cssesc": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/cssesc/-/cssesc-3.0.0.tgz",
"integrity": "sha512-/Tb/JcjK111nNScGob5MNtsntNM1aCNUDipB/TkwZFhyDrrE47SOx/18wF2bbjgc3ZzCSKW1T5nt5EbFoAz/Vg==",
"dev": true,
"bin": {
"cssesc": "bin/cssesc"
},
"engines": {
"node": ">=4"
}
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/data-uri-to-buffer": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"version": "6.0.2",
"resolved": "https://registry.npmjs.org/data-uri-to-buffer/-/data-uri-to-buffer-6.0.2.tgz",
"integrity": "sha512-7hvf7/GW8e86rW0ptuwS3OcBGDjIi6SZva7hCyWC0yYry2cOPmLIjXAUHI6DK2HsnwJd9ifmt57i8eV2n4YNpw==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"engines": {
"node": ">= 14"
}
},
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"node_modules/debug": {
"version": "4.3.4",
"resolved": "https://registry.npmjs.org/debug/-/debug-4.3.4.tgz",
"integrity": "sha512-PRWFHuSU3eDtQJPvnNY7Jcket1j0t5OuOsFzPPzsekD52Zl8qUfFIPEiswXqIvHWGVHOgX+7G/vCNNhehwxfkQ==",
"dev": true,
"license": "MIT",
"dependencies": {
"ms": "2.1.2"
},
"engines": {
"node": ">=6.0"
},
"peerDependenciesMeta": {
"supports-color": {
"optional": true
}
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/decompress-response": {
"version": "4.2.1",
"resolved": "https://registry.npmjs.org/decompress-response/-/decompress-response-4.2.1.tgz",
"integrity": "sha512-jOSne2qbyE+/r8G1VU+G/82LBs2Fs4LAsTiLSHOCOMZQl2OKZ6i8i4IyHemTe+/yIXOtTcRQMzPcgyhoFlqPkw==",
"dev": true,
"dependencies": {
"mimic-response": "^2.0.0"
},
"engines": {
"node": ">=8"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/deep-extend": {
"version": "0.6.0",
"resolved": "https://registry.npmjs.org/deep-extend/-/deep-extend-0.6.0.tgz",
"integrity": "sha512-LOHxIOaPYdHlJRtCQfDIVZtfw/ufM8+rVj649RIHzcm/vGwQRXFt6OPqIFWsm2XEMrNIEtWR64sY1LEKD2vAOA==",
"dev": true,
"engines": {
"node": ">=4.0.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/deep-is": {
"version": "0.1.3",
"resolved": "https://registry.npmjs.org/deep-is/-/deep-is-0.1.3.tgz",
"integrity": "sha1-s2nW+128E+7PUk+RsHD+7cNXzzQ=",
"dev": true
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/deepmerge": {
"version": "4.3.1",
"resolved": "https://registry.npmjs.org/deepmerge/-/deepmerge-4.3.1.tgz",
"integrity": "sha512-3sUqbMEc77XqpdNO7FRyRog+eW3ph+GYCbj+rK+uYyRMuwsVy0rMiVtPn+QJlKFvWP/1PYpapqYn0Me2knFn+A==",
"dev": true,
"license": "MIT",
"engines": {
"node": ">=0.10.0"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/default-require-extensions": {
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/default-require-extensions/-/default-require-extensions-3.0.1.tgz",
"integrity": "sha512-eXTJmRbm2TIt9MgWTsOH1wEuhew6XGZcMeGKCtLedIg/NCsg1iBePXkceTdK4Fii7pzmN9tGsZhKzZ4h7O/fxw==",
"dev": true,
"dependencies": {
"strip-bom": "^4.0.0"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/default-require-extensions/node_modules/strip-bom": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/strip-bom/-/strip-bom-4.0.0.tgz",
"integrity": "sha512-3xurFv5tEgii33Zi8Jtp55wEIILR9eh34FAW00PZf+JnSsTmV/ioewSgQl97JHvgjoRGwPShsWm+IdrxB35d0w==",
"dev": true,
"engines": {
"node": ">=8"
}
},
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"node_modules/define-data-property": {
"version": "1.1.1",
"resolved": "https://registry.npmjs.org/define-data-property/-/define-data-property-1.1.1.tgz",
"integrity": "sha512-E7uGkTzkk1d0ByLeSc6ZsFS79Axg+m1P/VsgYsxHgiuc3tFSj+MjMIwe90FC4lOAZzNBdY7kkO2P2wKdsQ1vgQ==",
"dev": true,
"peer": true,
"dependencies": {
"get-intrinsic": "^1.2.1",
"gopd": "^1.0.1",
"has-property-descriptors": "^1.0.0"
},
"engines": {
"node": ">= 0.4"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/define-properties": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/define-properties/-/define-properties-1.2.0.tgz",
"integrity": "sha512-xvqAVKGfT1+UAvPwKTVw/njhdQ8ZhXK4lI0bCIuCMrp2up9nPnaDftrLtmpTazqd1o+UY4zgzU+avtMbDP+ldA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2022-09-18 10:31:32 +02:00
"has-property-descriptors": "^1.0.0",
"object-keys": "^1.1.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">= 0.4"
Update npm packages
2022-09-18 10:31:32 +02:00
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/degenerator": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/degenerator/-/degenerator-5.0.1.tgz",
"integrity": "sha512-TllpMR/t0M5sqCXfj85i4XaAzxmS5tVA16dqvdkMwGmzI+dXLXnw3J+3Vdv7VKw+ThlTMboK6i9rnZ6Nntj5CQ==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"ast-types": "^0.13.4",
"escodegen": "^2.1.0",
"esprima": "^4.0.1"
},
"engines": {
"node": ">= 14"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/delayed-stream": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/delayed-stream/-/delayed-stream-1.0.0.tgz",
"integrity": "sha512-ZySD7Nf91aLB0RxL4KGrKHBXl7Eds1DAmEdcoVawXnLD7SDhpNgtuII2aAkg7a7QS41jxPSZ17p4VdGnMHk3MQ==",
"dev": true,
"engines": {
"node": ">=0.4.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/delegates": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/delegates/-/delegates-1.0.0.tgz",
"integrity": "sha1-hMbhWbgZBP3KWaDvRM2HDTElD5o=",
"dev": true
},
"node_modules/detect-file": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/detect-file/-/detect-file-1.0.0.tgz",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"integrity": "sha512-DtCOLG98P007x7wiiOmfI0fi3eIKyWiLTGJ2MDnVi/E04lWGbf+JzrRHMm0rgIIZJGtHpKpbVgLWHrv8xXpc3Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/detect-libc": {
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/detect-libc/-/detect-libc-1.0.3.tgz",
"integrity": "sha1-+hN8S9aY7fVc1c0CrFWfkaTEups=",
"dev": true,
"bin": {
"detect-libc": "bin/detect-libc.js"
},
"engines": {
"node": ">=0.10"
}
},
"node_modules/devtools-protocol": {
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"version": "0.0.1299070",
"resolved": "https://registry.npmjs.org/devtools-protocol/-/devtools-protocol-0.0.1299070.tgz",
"integrity": "sha512-+qtL3eX50qsJ7c+qVyagqi7AWMoQCBGNfoyJZMwm/NSXVqLYbuitrWEEIzxfUmTNy7//Xe8yhMmQ+elj3uAqSg==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "BSD-3-Clause"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"node_modules/dir-glob": {
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/dir-glob/-/dir-glob-3.0.1.tgz",
"integrity": "sha512-WkrWp9GR4KXfKGYzOLmTuGVi1UWFfws377n9cc55/tb6DuqyF6pcQ5AbiHEshaDpY9v6oaSr2XCDidGmMwdzIA==",
"dev": true,
"dependencies": {
"path-type": "^4.0.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/distributions": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/distributions/-/distributions-2.1.0.tgz",
"integrity": "sha512-4eov7WXRip5Tu0K7Y51W1oVt+DcvkoE0EzsvbLzgedC/n4PUpYXHqk6vo/OH1HteBHp5Vm6cmfnInf9NAXM4qQ==",
"dev": true,
"dependencies": {
"cephes": "^1.1.2"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/dlv": {
"version": "1.1.3",
"resolved": "https://registry.npmjs.org/dlv/-/dlv-1.1.3.tgz",
"integrity": "sha512-+HlytyjlPKnIG8XuRG8WvmBP8xs8P71y+SKKS6ZXWoEgLuePxtDoUEiH7WkdePWrQ5JBpE6aoVqfZfJUQkjXwA==",
"dev": true,
"license": "MIT"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/doctrine": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/doctrine/-/doctrine-3.0.0.tgz",
"integrity": "sha512-yS+Q5i3hBf7GBkd4KG8a7eBNNWNGLTaEwwYWUijIYM7zrlYDM0BFXHjjPWlWZ1Rg7UaddZeIDmi9jF3HmqiQ2w==",
"dev": true,
"dependencies": {
"esutils": "^2.0.2"
},
"engines": {
"node": ">=6.0.0"
}
},
Update npm packages
2022-07-24 08:54:23 +02:00
"node_modules/dom-serializer": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/dom-serializer/-/dom-serializer-2.0.0.tgz",
"integrity": "sha512-wIkAryiqt/nV5EQKqQpo3SToSOV9J0DnbJqwK7Wv/Trc92zIAYZ4FlMu+JPFW1DfGFt81ZTCGgDEabffXeLyJg==",
"dev": true,
"dependencies": {
"domelementtype": "^2.3.0",
"domhandler": "^5.0.2",
"entities": "^4.2.0"
},
"funding": {
"url": "https://github.com/cheeriojs/dom-serializer?sponsor=1"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Update npm packages
2022-07-24 08:54:23 +02:00
"node_modules/dom-serializer/node_modules/entities": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "4.5.0",
"resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz",
"integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==",
Update npm packages
2022-07-24 08:54:23 +02:00
"dev": true,
"engines": {
"node": ">=0.12"
},
"funding": {
"url": "https://github.com/fb55/entities?sponsor=1"
}
},
"node_modules/domelementtype": {
"version": "2.3.0",
"resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-2.3.0.tgz",
"integrity": "sha512-OLETBj6w0OsagBwdXnPdN0cnMfF9opN69co+7ZrbfPGrdpPVNBUj02spi6B1N7wChLQiPn4CSH/zJvXw56gmHw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/fb55"
}
]
},
Update npm packages
2022-07-24 08:54:23 +02:00
"node_modules/domhandler": {
Update npm packages
2022-10-29 10:17:36 +02:00
"version": "5.0.3",
"resolved": "https://registry.npmjs.org/domhandler/-/domhandler-5.0.3.tgz",
"integrity": "sha512-cgwlv/1iFQiFnU96XXgROh8xTeetsnJiDsTc7TYCLFd9+/WNkIqPTxiM/8pSd8VIrhXGTf1Ny1q1hquVqDJB5w==",
Update npm packages
2022-07-24 08:54:23 +02:00
"dev": true,
"dependencies": {
Update npm packages
2022-10-29 10:17:36 +02:00
"domelementtype": "^2.3.0"
Update npm packages
2022-07-24 08:54:23 +02:00
},
"engines": {
"node": ">= 4"
},
"funding": {
"url": "https://github.com/fb55/domhandler?sponsor=1"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/domutils": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "3.1.0",
"resolved": "https://registry.npmjs.org/domutils/-/domutils-3.1.0.tgz",
"integrity": "sha512-H78uMmQtI2AhgDJjWeQmHwJJ2bLPD3GMmO7Zja/ZZh84wkm+4ut+IUnUdRa8uCGX88DiVx1j6FRe1XfxEgjEZA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2022-10-29 10:17:36 +02:00
"dom-serializer": "^2.0.0",
"domelementtype": "^2.3.0",
Update npm packages
2024-03-17 13:50:21 +01:00
"domhandler": "^5.0.3"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
"url": "https://github.com/fb55/domutils?sponsor=1"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/dset": {
"version": "3.1.3",
"resolved": "https://registry.npmjs.org/dset/-/dset-3.1.3.tgz",
"integrity": "sha512-20TuZZHCEZ2O71q9/+8BwKwZ0QtD9D8ObhrihJPr+vLLYlSuAU3/zL4cSlgbfeoGHTjCSJBa7NGcrF9/Bx/WJQ==",
"dev": true,
"license": "MIT",
"engines": {
"node": ">=4"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/each-props": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/each-props/-/each-props-3.0.0.tgz",
"integrity": "sha512-IYf1hpuWrdzse/s/YJOrFmU15lyhSzxelNVAHTEG3DtP4QsLTWZUzcUL3HMXmKQxXpa4EIrBPpwRgj0aehdvAw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"is-plain-object": "^5.0.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"object.defaults": "^1.1.0"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
},
"engines": {
"node": ">= 10.13.0"
}
},
"node_modules/each-props/node_modules/is-plain-object": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/is-plain-object/-/is-plain-object-5.0.0.tgz",
"integrity": "sha512-VRSzKkbMm5jMDoKLbltAkFQ5Qr7VDiTFGXxYFXXowVj387GeGNOCsOH6Msy00SGZ3Fp84b1Naa1psqgcCIEP5Q==",
"dev": true,
"engines": {
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node_modules/eastasianwidth": {
"version": "0.2.0",
"resolved": "https://registry.npmjs.org/eastasianwidth/-/eastasianwidth-0.2.0.tgz",
"integrity": "sha512-I88TYZWc9XiYHRQ4/3c5rjjfgkjhLyW2luGIheGERbNQ6OY7yTybanSpDXZa8y7VUP9YmDcYa+eyq4ca7iLqWA==",
"dev": true
},
Update npm packages The new major version of `gulp-zip` shouldn't be a problem, given the changes listed in https://github.com/sindresorhus/gulp-zip/releases/tag/v6.0.0
2023-11-04 09:30:39 +01:00
"node_modules/easy-transform-stream": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/easy-transform-stream/-/easy-transform-stream-1.0.1.tgz",
"integrity": "sha512-ktkaa6XR7COAR3oj02CF3IOgz2m1hCaY3SfzvKT4Svt2MhHw9XCt+ncJNWfe2TGz31iqzNGZ8spdKQflj+Rlog==",
"dev": true,
"engines": {
"node": ">=14.16"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/electron-to-chromium": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "1.4.827",
"resolved": "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.4.827.tgz",
"integrity": "sha512-VY+J0e4SFcNfQy19MEoMdaIcZLmDCprqvBtkii1WTCTQHpRvf5N8+3kTYCgL/PcntvwQvmMJWTuDPsq+IlhWKQ==",
"dev": true,
"license": "ISC"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"node_modules/emoji-regex": {
"version": "8.0.0",
"resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz",
"integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==",
"dev": true
},
"node_modules/end-of-stream": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "1.4.4",
"resolved": "https://registry.npmjs.org/end-of-stream/-/end-of-stream-1.4.4.tgz",
"integrity": "sha512-+uw1inIHVPQoaVuHzRyXd21icM+cnt4CzD5rW+NC1wjOUSTOs+Te7FOv7AhN7vS9x/oIyhLP5PR1H+phQAHu5Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"once": "^1.4.0"
}
},
"node_modules/enhanced-resolve": {
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"version": "5.17.0",
"resolved": "https://registry.npmjs.org/enhanced-resolve/-/enhanced-resolve-5.17.0.tgz",
"integrity": "sha512-dwDPwZL0dmye8Txp2gzFmA6sxALaSvdRDjPH0viLcKrtlOL3tw62nWWweVD1SdILDTJrbrL6tdWVN58Wo6U3eA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"graceful-fs": "^4.2.4",
"tapable": "^2.2.0"
},
"engines": {
"node": ">=10.13.0"
}
},
"node_modules/entities": {
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/entities/-/entities-3.0.1.tgz",
"integrity": "sha512-WiyBqoomrwMdFG1e0kqvASYfnlb0lp8M5o5Fw2OFq1hNZxxcNk8Ik0Xm7LxzBhuidnZB/UtBqVCgUz3kBOP51Q==",
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"peer": true,
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"engines": {
"node": ">=0.12"
},
"funding": {
"url": "https://github.com/fb55/entities?sponsor=1"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Update npm packages
2023-12-23 12:29:51 +01:00
"node_modules/env-paths": {
"version": "2.2.1",
"resolved": "https://registry.npmjs.org/env-paths/-/env-paths-2.2.1.tgz",
"integrity": "sha512-+h1lkLKhZMTYjog1VEpJNG7NZJWcuc2DDk/qsqSTRRCOXiLjeQ1d1/udrUGhqMxUgAlwKNZ0cf2uqan5GLuS2A==",
"dev": true,
"engines": {
"node": ">=6"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/errno": {
"version": "0.1.8",
"resolved": "https://registry.npmjs.org/errno/-/errno-0.1.8.tgz",
"integrity": "sha512-dJ6oBr5SQ1VSd9qkk7ByRgb/1SH4JZjCHSW/mr63/QcXO9zLVxvJ6Oy13nio03rxpSnVDDjFor75SjVeZWPW/A==",
"dev": true,
"dependencies": {
"prr": "~1.0.1"
},
"bin": {
"errno": "cli.js"
}
},
"node_modules/error-ex": {
"version": "1.3.1",
"resolved": "https://registry.npmjs.org/error-ex/-/error-ex-1.3.1.tgz",
"integrity": "sha1-+FWobOYa3E6GIcPNoh56dhLDqNw=",
"dev": true,
"dependencies": {
"is-arrayish": "^0.2.1"
}
},
"node_modules/es-abstract": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "1.22.1",
"resolved": "https://registry.npmjs.org/es-abstract/-/es-abstract-1.22.1.tgz",
"integrity": "sha512-ioRRcXMO6OFyRpyzV3kE1IIBd4WG5/kltnzdxSCqoP8CMGs/Li+M1uF5o7lOkZVFjDs+NLesthnF66Pg/0q0Lw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2023-08-06 09:22:20 +02:00
"array-buffer-byte-length": "^1.0.0",
"arraybuffer.prototype.slice": "^1.0.1",
Update npm packages
2023-01-15 10:34:56 +01:00
"available-typed-arrays": "^1.0.5",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"call-bind": "^1.0.2",
Update npm packages
2023-01-15 10:34:56 +01:00
"es-set-tostringtag": "^2.0.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"es-to-primitive": "^1.2.1",
Update npm packages
2022-09-18 10:31:32 +02:00
"function.prototype.name": "^1.1.5",
Update npm packages
2023-08-06 09:22:20 +02:00
"get-intrinsic": "^1.2.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"get-symbol-description": "^1.0.0",
Update npm packages
2023-01-15 10:34:56 +01:00
"globalthis": "^1.0.3",
"gopd": "^1.0.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"has": "^1.0.3",
Update npm packages
2022-09-18 10:31:32 +02:00
"has-property-descriptors": "^1.0.0",
Update npm packages
2023-01-15 10:34:56 +01:00
"has-proto": "^1.0.1",
Update npm packages
2022-09-18 10:31:32 +02:00
"has-symbols": "^1.0.3",
Update npm packages
2023-08-06 09:22:20 +02:00
"internal-slot": "^1.0.5",
"is-array-buffer": "^3.0.2",
Update npm packages
2023-01-15 10:34:56 +01:00
"is-callable": "^1.2.7",
Update npm packages
2022-09-18 10:31:32 +02:00
"is-negative-zero": "^2.0.2",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"is-regex": "^1.1.4",
Update npm packages
2022-09-18 10:31:32 +02:00
"is-shared-array-buffer": "^1.0.2",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"is-string": "^1.0.7",
Update npm packages
2023-01-15 10:34:56 +01:00
"is-typed-array": "^1.1.10",
Update npm packages
2022-09-18 10:31:32 +02:00
"is-weakref": "^1.0.2",
Update npm packages
2023-08-06 09:22:20 +02:00
"object-inspect": "^1.12.3",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"object-keys": "^1.1.1",
Update npm packages
2022-09-18 10:31:32 +02:00
"object.assign": "^4.1.4",
Update npm packages
2023-08-06 09:22:20 +02:00
"regexp.prototype.flags": "^1.5.0",
"safe-array-concat": "^1.0.0",
Update npm packages
2023-01-15 10:34:56 +01:00
"safe-regex-test": "^1.0.0",
Update npm packages
2023-08-06 09:22:20 +02:00
"string.prototype.trim": "^1.2.7",
Update npm packages
2023-01-15 10:34:56 +01:00
"string.prototype.trimend": "^1.0.6",
"string.prototype.trimstart": "^1.0.6",
Update npm packages
2023-08-06 09:22:20 +02:00
"typed-array-buffer": "^1.0.0",
"typed-array-byte-length": "^1.0.0",
"typed-array-byte-offset": "^1.0.0",
Update npm packages
2023-01-15 10:34:56 +01:00
"typed-array-length": "^1.0.4",
"unbox-primitive": "^1.0.2",
Update npm packages
2023-08-06 09:22:20 +02:00
"which-typed-array": "^1.1.10"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/es-module-lexer": {
Update npm packages
2023-04-15 22:08:58 +02:00
"version": "1.2.1",
"resolved": "https://registry.npmjs.org/es-module-lexer/-/es-module-lexer-1.2.1.tgz",
"integrity": "sha512-9978wrXM50Y4rTMmW5kXIC09ZdXQZqkE4mxhwkd8VbzsGkXGPgV4zWuqQJgCEzYngdo2dYDa0l8xhX4fkSwJSg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
Update npm packages
2023-01-15 10:34:56 +01:00
"node_modules/es-set-tostringtag": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/es-set-tostringtag/-/es-set-tostringtag-2.0.1.tgz",
"integrity": "sha512-g3OMbtlwY3QewlqAiMLI47KywjWZoEytKr8pf6iTC8uJq5bIAH52Z9pnQ8pVL6whrCto53JZDuUIsifGeLorTg==",
"dev": true,
"dependencies": {
"get-intrinsic": "^1.1.3",
"has": "^1.0.3",
"has-tostringtag": "^1.0.0"
},
"engines": {
"node": ">= 0.4"
}
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/es-shim-unscopables": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/es-shim-unscopables/-/es-shim-unscopables-1.0.0.tgz",
"integrity": "sha512-Jm6GPcCdC30eMLbZ2x8z2WuRwAws3zTBBKuusffYVUrNj/GVSUAZ+xKMaUpfNDR5IbyNA5LJbaecoUVbmUcB1w==",
"dev": true,
"dependencies": {
"has": "^1.0.3"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/es-to-primitive": {
"version": "1.2.1",
"resolved": "https://registry.npmjs.org/es-to-primitive/-/es-to-primitive-1.2.1.tgz",
"integrity": "sha512-QCOllgZJtaUo9miYBcLChTUaHNjJF3PYs1VidD7AwiEj1kYxKeQTctLAezAOH5ZKRH0g2IgPn6KwB4IT8iRpvA==",
"dev": true,
"dependencies": {
"is-callable": "^1.1.4",
"is-date-object": "^1.0.1",
"is-symbol": "^1.0.2"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/escalade": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "3.1.2",
"resolved": "https://registry.npmjs.org/escalade/-/escalade-3.1.2.tgz",
"integrity": "sha512-ErCHMCae19vR8vQGe50xIsVomy19rg6gFu3+r3jkEO46suLMWBksvVyoGgQV+jOfl84ZSOSlmv6Gxa89PmTGmA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=6"
}
},
"node_modules/escape-string-regexp": {
"version": "1.0.5",
"resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz",
"integrity": "sha1-G2HAViGQqN/2rjuyzwIAyhMLhtQ=",
"dev": true,
"engines": {
"node": ">=0.8.0"
}
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/escodegen": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/escodegen/-/escodegen-2.1.0.tgz",
"integrity": "sha512-2NlIDTwUWJN0mRPQOdtQBzbUHvdGY2P1VXSyU83Q3xKxM7WHX2Ql8dKq782Q9TgQUNOLEzEYu9bzLNj1q88I5w==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "BSD-2-Clause",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"esprima": "^4.0.1",
"estraverse": "^5.2.0",
"esutils": "^2.0.2"
},
"bin": {
"escodegen": "bin/escodegen.js",
"esgenerate": "bin/esgenerate.js"
},
"engines": {
"node": ">=6.0"
},
"optionalDependencies": {
"source-map": "~0.6.1"
}
},
"node_modules/escodegen/node_modules/estraverse": {
"version": "5.3.0",
"resolved": "https://registry.npmjs.org/estraverse/-/estraverse-5.3.0.tgz",
"integrity": "sha512-MMdARuVEQziNTeJD8DgMqmhwR11BRQ/cBP+pLtYdSTnf3MIO8fFeiINEbX36ZdNlfU/7A9f3gUw49B3oQsvwBA==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "BSD-2-Clause",
Update npm packages
2023-07-23 09:49:53 +02:00
"engines": {
"node": ">=4.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "8.57.0",
"resolved": "https://registry.npmjs.org/eslint/-/eslint-8.57.0.tgz",
"integrity": "sha512-dZ6+mexnaTIbSBZWgou51U6OmzIhYM2VcNdtiTtI7qPNZm35Akpr0f6vtw3w1Kmn5PYo+tZVfh13WrhpS6oLqQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2023-03-12 10:27:52 +01:00
"@eslint-community/eslint-utils": "^4.2.0",
Update npm packages
2023-08-06 09:22:20 +02:00
"@eslint-community/regexpp": "^4.6.1",
Update npm packages
2023-12-23 12:29:51 +01:00
"@eslint/eslintrc": "^2.1.4",
Update npm packages
2024-03-17 13:50:21 +01:00
"@eslint/js": "8.57.0",
"@humanwhocodes/config-array": "^0.11.14",
Update npm packages
2022-09-04 09:57:59 +02:00
"@humanwhocodes/module-importer": "^1.0.1",
Update npm packages
2022-10-29 10:17:36 +02:00
"@nodelib/fs.walk": "^1.2.8",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"@ungap/structured-clone": "^1.2.0",
Update npm packages
2023-08-06 09:22:20 +02:00
"ajv": "^6.12.4",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"chalk": "^4.0.0",
"cross-spawn": "^7.0.2",
"debug": "^4.3.2",
"doctrine": "^3.0.0",
"escape-string-regexp": "^4.0.0",
Update npm packages
2023-08-06 09:22:20 +02:00
"eslint-scope": "^7.2.2",
Update npm packages
2023-08-19 09:08:11 +02:00
"eslint-visitor-keys": "^3.4.3",
Update npm packages
2023-08-06 09:22:20 +02:00
"espree": "^9.6.1",
Update npm packages
2023-03-12 10:27:52 +01:00
"esquery": "^1.4.2",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"esutils": "^2.0.2",
"fast-deep-equal": "^3.1.3",
"file-entry-cache": "^6.0.1",
Update npm packages
2022-08-07 10:20:21 +02:00
"find-up": "^5.0.0",
Update npm packages
2022-10-29 10:17:36 +02:00
"glob-parent": "^6.0.2",
Update npm packages
2022-12-25 12:26:23 +01:00
"globals": "^13.19.0",
Update npm packages
2023-05-28 09:39:34 +02:00
"graphemer": "^1.4.0",
Update npm packages
2022-01-23 10:58:15 +01:00
"ignore": "^5.2.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"imurmurhash": "^0.1.4",
"is-glob": "^4.0.0",
Update npm packages
2022-10-29 10:17:36 +02:00
"is-path-inside": "^3.0.3",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"js-yaml": "^4.1.0",
"json-stable-stringify-without-jsonify": "^1.0.1",
"levn": "^0.4.1",
"lodash.merge": "^4.6.2",
Update npm packages
2022-05-15 09:02:57 +02:00
"minimatch": "^3.1.2",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"natural-compare": "^1.4.0",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"optionator": "^0.9.3",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"strip-ansi": "^6.0.1",
Update npm packages
2022-09-04 09:57:59 +02:00
"text-table": "^0.2.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"bin": {
"eslint": "bin/eslint.js"
},
"engines": {
"node": "^12.22.0 || ^14.17.0 || >=16.0.0"
},
"funding": {
"url": "https://opencollective.com/eslint"
}
},
"node_modules/eslint-config-prettier": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "9.1.0",
"resolved": "https://registry.npmjs.org/eslint-config-prettier/-/eslint-config-prettier-9.1.0.tgz",
"integrity": "sha512-NSWl5BFQWEPi1j4TjVNItzYV7dZXZ+wP6I6ZhrBGpChQhZRUaElihE9uRRkcbRnNb76UMKDF3r+WTmNcGPKsqw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"bin": {
"eslint-config-prettier": "bin/cli.js"
},
"peerDependencies": {
"eslint": ">=7.0.0"
}
},
"node_modules/eslint-import-resolver-node": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"version": "0.3.9",
"resolved": "https://registry.npmjs.org/eslint-import-resolver-node/-/eslint-import-resolver-node-0.3.9.tgz",
"integrity": "sha512-WFj2isz22JahUv+B788TlO3N6zL3nNJGU8CcZbPZvVEkBPaJdCV4vy5wyghty5ROFbCRnm132v8BScu5/1BQ8g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"debug": "^3.2.7",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"is-core-module": "^2.13.0",
"resolve": "^1.22.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/eslint-import-resolver-node/node_modules/debug": {
"version": "3.2.7",
"resolved": "https://registry.npmjs.org/debug/-/debug-3.2.7.tgz",
"integrity": "sha512-CFjzYYAi4ThfiQvizrFQevTTXHtnCqWfe7x1AhgEscTz6ZbLbfoLRLPugTQyBth6f8ZERVUSyWHFD/7Wu4t1XQ==",
"dev": true,
"dependencies": {
"ms": "^2.1.1"
}
},
"node_modules/eslint-import-resolver-node/node_modules/ms": {
"version": "2.1.3",
"resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz",
"integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==",
"dev": true
},
"node_modules/eslint-module-utils": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "2.8.0",
"resolved": "https://registry.npmjs.org/eslint-module-utils/-/eslint-module-utils-2.8.0.tgz",
"integrity": "sha512-aWajIYfsqCKRDgUfjEXNN/JlrzauMuSEy5sbd7WXbtW3EH6A6MpwEh42c7qD+MqQo9QMJ6fWLAeIJynx0g6OAw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2023-01-15 10:34:56 +01:00
"debug": "^3.2.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=4"
Update npm packages
2023-01-15 10:34:56 +01:00
},
"peerDependenciesMeta": {
"eslint": {
"optional": true
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/eslint-module-utils/node_modules/debug": {
"version": "3.2.7",
"resolved": "https://registry.npmjs.org/debug/-/debug-3.2.7.tgz",
"integrity": "sha512-CFjzYYAi4ThfiQvizrFQevTTXHtnCqWfe7x1AhgEscTz6ZbLbfoLRLPugTQyBth6f8ZERVUSyWHFD/7Wu4t1XQ==",
"dev": true,
"dependencies": {
"ms": "^2.1.1"
}
},
"node_modules/eslint-module-utils/node_modules/ms": {
"version": "2.1.3",
"resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz",
"integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==",
"dev": true
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/eslint-plugin-es": {
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/eslint-plugin-es/-/eslint-plugin-es-3.0.1.tgz",
"integrity": "sha512-GUmAsJaN4Fc7Gbtl8uOBlayo2DqhwWvEzykMHSCZHU3XdJ+NSzzZcVhXh3VxX5icqQ+oQdIEawXX8xkR3mIFmQ==",
"dev": true,
"peer": true,
"dependencies": {
"eslint-utils": "^2.0.0",
"regexpp": "^3.0.0"
},
"engines": {
"node": ">=8.10.0"
},
"funding": {
"url": "https://github.com/sponsors/mysticatea"
},
"peerDependencies": {
"eslint": ">=4.19.1"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-plugin-fetch-options": {
"version": "0.0.5",
"resolved": "https://registry.npmjs.org/eslint-plugin-fetch-options/-/eslint-plugin-fetch-options-0.0.5.tgz",
"integrity": "sha512-ZMxrccsOAZ7uMQ4nMvPJLqLg6oyLF96YOEwTKWAIbDHpwWUp1raXALZom8ikKucaEnhqWSRuBWI8jBXveFwkJg==",
"dev": true,
"engines": {
"node": ">=0.9.0"
}
},
"node_modules/eslint-plugin-html": {
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"version": "8.1.1",
"resolved": "https://registry.npmjs.org/eslint-plugin-html/-/eslint-plugin-html-8.1.1.tgz",
"integrity": "sha512-6qmlJsc40D2m3Dn9oEH+0PAOkJhxVu0f5sVItqpCE0YWgYnyP4xCjBc3UWTHaJcY9ARkWOLIIuXLq0ndRnQOHw==",
Update npm packages
2022-07-24 08:54:23 +02:00
"dev": true,
"dependencies": {
Update npm packages
2024-03-17 13:50:21 +01:00
"htmlparser2": "^9.1.0"
},
"engines": {
"node": ">=16.0.0"
Update npm packages
2022-07-24 08:54:23 +02:00
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-plugin-import": {
Update npm packages
2023-12-23 12:29:51 +01:00
"version": "2.29.1",
"resolved": "https://registry.npmjs.org/eslint-plugin-import/-/eslint-plugin-import-2.29.1.tgz",
"integrity": "sha512-BbPC0cuExzhiMo4Ff1BTVwHpjjv28C5R+btTOGaCRC7UEz801up0JadwkeSk5Ued6TG34uaczuVuH6qyy5YUxw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"array-includes": "^3.1.7",
"array.prototype.findlastindex": "^1.2.3",
"array.prototype.flat": "^1.3.2",
"array.prototype.flatmap": "^1.3.2",
Update npm packages
2023-01-15 10:34:56 +01:00
"debug": "^3.2.7",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"doctrine": "^2.1.0",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"eslint-import-resolver-node": "^0.3.9",
Update npm packages
2023-08-06 09:22:20 +02:00
"eslint-module-utils": "^2.8.0",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"hasown": "^2.0.0",
"is-core-module": "^2.13.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"is-glob": "^4.0.3",
Update npm packages
2022-04-17 10:15:10 +02:00
"minimatch": "^3.1.2",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"object.fromentries": "^2.0.7",
"object.groupby": "^1.0.1",
"object.values": "^1.1.7",
Update npm packages
2023-08-06 09:22:20 +02:00
"semver": "^6.3.1",
Update npm packages
2023-12-23 12:29:51 +01:00
"tsconfig-paths": "^3.15.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=4"
},
"peerDependencies": {
"eslint": "^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8"
}
},
Update npm packages
2023-01-15 10:34:56 +01:00
"node_modules/eslint-plugin-import/node_modules/debug": {
"version": "3.2.7",
"resolved": "https://registry.npmjs.org/debug/-/debug-3.2.7.tgz",
"integrity": "sha512-CFjzYYAi4ThfiQvizrFQevTTXHtnCqWfe7x1AhgEscTz6ZbLbfoLRLPugTQyBth6f8ZERVUSyWHFD/7Wu4t1XQ==",
"dev": true,
"dependencies": {
"ms": "^2.1.1"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-plugin-import/node_modules/doctrine": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/doctrine/-/doctrine-2.1.0.tgz",
"integrity": "sha512-35mSku4ZXK0vfCuHEDAwt55dg2jNajHZ1odvF+8SSr82EsZY4QmXfuWso8oEd8zRhVObSN18aM0CjSdoBX7zIw==",
"dev": true,
"dependencies": {
"esutils": "^2.0.2"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/eslint-plugin-import/node_modules/is-glob": {
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz",
"integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==",
"dev": true,
"dependencies": {
"is-extglob": "^2.1.1"
},
"engines": {
"node": ">=0.10.0"
}
},
Update npm packages
2023-01-15 10:34:56 +01:00
"node_modules/eslint-plugin-import/node_modules/ms": {
"version": "2.1.3",
"resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz",
"integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==",
"dev": true
},
"node_modules/eslint-plugin-import/node_modules/semver": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "6.3.1",
"resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz",
"integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==",
Update npm packages
2023-01-15 10:34:56 +01:00
"dev": true,
"bin": {
"semver": "bin/semver.js"
}
},
Avoid to have focused tests in using eslint-plugin-jasmine
2024-01-20 21:42:37 +01:00
"node_modules/eslint-plugin-jasmine": {
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"version": "4.2.0",
"resolved": "https://registry.npmjs.org/eslint-plugin-jasmine/-/eslint-plugin-jasmine-4.2.0.tgz",
"integrity": "sha512-zSCsnP4gMqBSt8jApExP0ja43nAI1fpAD5kY+knrIJylBxC/LEth25PkqcKJqW32GjesjsiA1SSSR3Z5qIranA==",
Avoid to have focused tests in using eslint-plugin-jasmine
2024-01-20 21:42:37 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"license": "MIT",
Avoid to have focused tests in using eslint-plugin-jasmine
2024-01-20 21:42:37 +01:00
"engines": {
"node": ">=8",
"npm": ">=6"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-plugin-json": {
"version": "3.1.0",
"resolved": "https://registry.npmjs.org/eslint-plugin-json/-/eslint-plugin-json-3.1.0.tgz",
"integrity": "sha512-MrlG2ynFEHe7wDGwbUuFPsaT2b1uhuEFhJ+W1f1u+1C2EkXmTYJp4B1aAdQQ8M+CC3t//N/oRKiIVw14L2HR1g==",
"dev": true,
"dependencies": {
"lodash": "^4.17.21",
"vscode-json-languageservice": "^4.1.6"
},
"engines": {
"node": ">=12.0"
}
},
"node_modules/eslint-plugin-mozilla": {
Update dependencies to the most recent versions
2024-05-23 15:59:27 +02:00
"version": "3.7.4",
"resolved": "https://registry.npmjs.org/eslint-plugin-mozilla/-/eslint-plugin-mozilla-3.7.4.tgz",
"integrity": "sha512-cYVwBG/9Ddei05DJs+1CMbE8W5PrJuZ7lLdnuA11LwuNhEjowrRYaQHEWB3FCKS5n6DR3Wt+kWOceYCvATQW1Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-23 15:59:27 +02:00
"license": "MPL-2.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update npm packages
2024-03-17 13:50:21 +01:00
"eslint-scope": "^7.2.2",
"eslint-visitor-keys": "^3.4.3",
"espree": "^9.6.1",
Update npm packages
2022-05-29 09:28:39 +02:00
"estraverse": "^5.3.0",
Update npm packages
2024-03-17 13:50:21 +01:00
"htmlparser2": "^9.1.0",
"toml-eslint-parser": "0.9.3"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update npm packages
2022-10-29 10:17:36 +02:00
"node": ">=14.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependencies": {
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"@microsoft/eslint-plugin-sdl": "^0.2.2",
Update npm packages
2022-04-17 10:15:10 +02:00
"eslint": "^7.23.0 || ^8.0.0",
Update npm packages
2024-03-17 13:50:21 +01:00
"eslint-config-prettier": "^8.0.0 || ^9.0.0",
"eslint-plugin-html": "^7.0.0 || ^8.0.0",
Update packages
2023-09-09 15:28:17 +02:00
"eslint-plugin-json": "^3.1.0",
Update `eslint-plugin-mozilla` to avoid having to force-install packages (issue 15429) The latest version of `eslint-plugin-mozilla` removed the Prettier dependency, see https://bugzilla.mozilla.org/show_bug.cgi?id=1677562, which means that we no longer need to use `npm install --force` in the PDF.js library.
2023-04-20 16:09:13 +02:00
"eslint-plugin-no-unsanitized": "^4.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update npm packages
2022-05-29 09:28:39 +02:00
"node_modules/eslint-plugin-mozilla/node_modules/eslint-scope": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "7.2.2",
"resolved": "https://registry.npmjs.org/eslint-scope/-/eslint-scope-7.2.2.tgz",
"integrity": "sha512-dOt21O7lTMhDM+X9mB4GX+DZrZtCUJPL/wlcTqxyrx5IvO0IYtILdtrQGQp+8n5S0gwSVmOf9NQrjMOgfQZlIg==",
Update npm packages
2022-05-29 09:28:39 +02:00
"dev": true,
"dependencies": {
"esrecurse": "^4.3.0",
"estraverse": "^5.2.0"
},
"engines": {
"node": "^12.22.0 || ^14.17.0 || >=16.0.0"
Update npm packages
2024-03-17 13:50:21 +01:00
},
"funding": {
"url": "https://opencollective.com/eslint"
Update npm packages
2022-05-29 09:28:39 +02:00
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-plugin-mozilla/node_modules/estraverse": {
Update npm packages
2022-05-29 09:28:39 +02:00
"version": "5.3.0",
"resolved": "https://registry.npmjs.org/estraverse/-/estraverse-5.3.0.tgz",
"integrity": "sha512-MMdARuVEQziNTeJD8DgMqmhwR11BRQ/cBP+pLtYdSTnf3MIO8fFeiINEbX36ZdNlfU/7A9f3gUw49B3oQsvwBA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=4.0"
}
},
"node_modules/eslint-plugin-no-unsanitized": {
Update npm packages
2022-11-27 10:18:30 +01:00
"version": "4.0.2",
"resolved": "https://registry.npmjs.org/eslint-plugin-no-unsanitized/-/eslint-plugin-no-unsanitized-4.0.2.tgz",
"integrity": "sha512-Pry0S9YmHoz8NCEMRQh7N0Yexh2MYCNPIlrV52hTmS7qXnTghWsjXouF08bgsrrZqaW9tt1ZiK3j5NEmPE+EjQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"peerDependencies": {
"eslint": "^6 || ^7 || ^8"
}
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/eslint-plugin-node": {
"version": "11.1.0",
"resolved": "https://registry.npmjs.org/eslint-plugin-node/-/eslint-plugin-node-11.1.0.tgz",
"integrity": "sha512-oUwtPJ1W0SKD0Tr+wqu92c5xuCeQqB3hSCHasn/ZgjFdA9iDGNkNf2Zi9ztY7X+hNuMib23LNGRm6+uN+KLE3g==",
"dev": true,
"peer": true,
"dependencies": {
"eslint-plugin-es": "^3.0.0",
"eslint-utils": "^2.0.0",
"ignore": "^5.1.1",
"minimatch": "^3.0.4",
"resolve": "^1.10.1",
"semver": "^6.1.0"
},
"engines": {
"node": ">=8.10.0"
},
"peerDependencies": {
"eslint": ">=5.16.0"
}
},
"node_modules/eslint-plugin-node/node_modules/semver": {
Fix dependency vulnerabilities with `npm audit fix`
2023-10-14 13:46:57 +02:00
"version": "6.3.1",
"resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz",
"integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true,
"peer": true,
"bin": {
"semver": "bin/semver.js"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-plugin-prettier": {
Update npm packages
2024-01-20 09:40:33 +01:00
"version": "5.1.3",
"resolved": "https://registry.npmjs.org/eslint-plugin-prettier/-/eslint-plugin-prettier-5.1.3.tgz",
"integrity": "sha512-C9GCVAs4Eq7ZC/XFQHITLiHJxQngdtraXaM+LoUFoFp/lHNl2Zn8f3WQbe9HvTBBQ9YnKFB0/2Ajdqwo5D1EAw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"prettier-linter-helpers": "^1.0.0",
Update npm packages
2024-01-06 10:09:12 +01:00
"synckit": "^0.8.6"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node": "^14.18.0 || >=16.0.0"
},
"funding": {
Update npm packages
2024-01-06 10:09:12 +01:00
"url": "https://opencollective.com/eslint-plugin-prettier"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"@types/eslint": ">=8.0.0",
"eslint": ">=8.0.0",
Update npm packages
2023-12-23 12:29:51 +01:00
"eslint-config-prettier": "*",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"prettier": ">=3.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependenciesMeta": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"@types/eslint": {
"optional": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"eslint-config-prettier": {
"optional": true
}
}
},
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"node_modules/eslint-plugin-react": {
"version": "7.33.0",
"resolved": "https://registry.npmjs.org/eslint-plugin-react/-/eslint-plugin-react-7.33.0.tgz",
"integrity": "sha512-qewL/8P34WkY8jAqdQxsiL82pDUeT7nhs8IsuXgfgnsEloKCT4miAV9N9kGtx7/KM9NH/NCGUE7Edt9iGxLXFw==",
"dev": true,
"peer": true,
"dependencies": {
"array-includes": "^3.1.6",
"array.prototype.flatmap": "^1.3.1",
"array.prototype.tosorted": "^1.1.1",
"doctrine": "^2.1.0",
"estraverse": "^5.3.0",
"jsx-ast-utils": "^2.4.1 || ^3.0.0",
"minimatch": "^3.1.2",
"object.entries": "^1.1.6",
"object.fromentries": "^2.0.6",
"object.hasown": "^1.1.2",
"object.values": "^1.1.6",
"prop-types": "^15.8.1",
"resolve": "^2.0.0-next.4",
"semver": "^6.3.1",
"string.prototype.matchall": "^4.0.8"
},
"engines": {
"node": ">=4"
},
"peerDependencies": {
"eslint": "^3 || ^4 || ^5 || ^6 || ^7 || ^8"
}
},
"node_modules/eslint-plugin-react/node_modules/doctrine": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/doctrine/-/doctrine-2.1.0.tgz",
"integrity": "sha512-35mSku4ZXK0vfCuHEDAwt55dg2jNajHZ1odvF+8SSr82EsZY4QmXfuWso8oEd8zRhVObSN18aM0CjSdoBX7zIw==",
"dev": true,
"peer": true,
"dependencies": {
"esutils": "^2.0.2"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/eslint-plugin-react/node_modules/estraverse": {
"version": "5.3.0",
"resolved": "https://registry.npmjs.org/estraverse/-/estraverse-5.3.0.tgz",
"integrity": "sha512-MMdARuVEQziNTeJD8DgMqmhwR11BRQ/cBP+pLtYdSTnf3MIO8fFeiINEbX36ZdNlfU/7A9f3gUw49B3oQsvwBA==",
"dev": true,
"peer": true,
"engines": {
"node": ">=4.0"
}
},
"node_modules/eslint-plugin-react/node_modules/resolve": {
"version": "2.0.0-next.5",
"resolved": "https://registry.npmjs.org/resolve/-/resolve-2.0.0-next.5.tgz",
"integrity": "sha512-U7WjGVG9sH8tvjW5SmGbQuui75FiyjAX72HX15DwBBwF9dNiQZRQAg9nnPhYy+TUnE0+VcrttuvNI8oSxZcocA==",
"dev": true,
"peer": true,
"dependencies": {
"is-core-module": "^2.13.0",
"path-parse": "^1.0.7",
"supports-preserve-symlinks-flag": "^1.0.0"
},
"bin": {
"resolve": "bin/resolve"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/eslint-plugin-react/node_modules/semver": {
"version": "6.3.1",
"resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz",
"integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==",
"dev": true,
"peer": true,
"bin": {
"semver": "bin/semver.js"
}
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/eslint-plugin-security": {
"version": "1.4.0",
"resolved": "https://registry.npmjs.org/eslint-plugin-security/-/eslint-plugin-security-1.4.0.tgz",
"integrity": "sha512-xlS7P2PLMXeqfhyf3NpqbvbnW04kN8M9NtmhpR3XGyOvt/vNKS7XPXT5EDbwKW9vCjWH4PpfQvgD/+JgN0VJKA==",
"dev": true,
"peer": true,
"dependencies": {
"safe-regex": "^1.1.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-plugin-sort-exports": {
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"version": "0.9.1",
"resolved": "https://registry.npmjs.org/eslint-plugin-sort-exports/-/eslint-plugin-sort-exports-0.9.1.tgz",
"integrity": "sha512-2w6jHusdF2K60bcGKpa9HEinETwNzVrvplZipVculCfu3ZDd5IW3xL54XVEnVkGIPJnp/LitFCg7owL4DOtuHg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"dependencies": {
"minimatch": "^9.0.3"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"peerDependencies": {
"eslint": ">=5.0.0"
}
},
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"node_modules/eslint-plugin-sort-exports/node_modules/brace-expansion": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz",
"integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==",
"dev": true,
"dependencies": {
"balanced-match": "^1.0.0"
}
},
"node_modules/eslint-plugin-sort-exports/node_modules/minimatch": {
"version": "9.0.3",
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.3.tgz",
"integrity": "sha512-RHiac9mvaRw0x3AYRgDC1CxAP7HTcNrrECeA8YYJeWnpo+2Q5CegtZjaotWTWxDG3UeGA1coE05iH1mPjT/2mg==",
"dev": true,
"dependencies": {
"brace-expansion": "^2.0.1"
},
"engines": {
"node": ">=16 || 14 >=14.17"
},
"funding": {
"url": "https://github.com/sponsors/isaacs"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-plugin-unicorn": {
Upgrade `eslint-plugin-unicorn` to version 54.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v54.0.0 doesn't indicate any breaking changes that should impact us.
2024-06-18 18:37:32 +02:00
"version": "54.0.0",
"resolved": "https://registry.npmjs.org/eslint-plugin-unicorn/-/eslint-plugin-unicorn-54.0.0.tgz",
"integrity": "sha512-XxYLRiYtAWiAjPv6z4JREby1TAE2byBC7wlh0V4vWDCpccOSU1KovWV//jqPXF6bq3WKxqX9rdjoRQ1EhdmNdQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `eslint-plugin-unicorn` to version 54.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v54.0.0 doesn't indicate any breaking changes that should impact us.
2024-06-18 18:37:32 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `eslint-plugin-unicorn` to version 53.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v53.0.0 doesn't indicate any breaking changes that should impact us. Most notably it contains support for ESLint 9, which brings us a step closer towards #17928.
2024-05-14 16:23:36 +02:00
"@babel/helper-validator-identifier": "^7.24.5",
Update npm packages
2023-05-14 10:12:06 +02:00
"@eslint-community/eslint-utils": "^4.4.0",
Upgrade `eslint-plugin-unicorn` to version 53.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v53.0.0 doesn't indicate any breaking changes that should impact us. Most notably it contains support for ESLint 9, which brings us a step closer towards #17928.
2024-05-14 16:23:36 +02:00
"@eslint/eslintrc": "^3.0.2",
Update npm packages
2023-12-23 12:29:51 +01:00
"ci-info": "^4.0.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"clean-regexp": "^1.0.0",
Upgrade `eslint-plugin-unicorn` to version 53.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v53.0.0 doesn't indicate any breaking changes that should impact us. Most notably it contains support for ESLint 9, which brings us a step closer towards #17928.
2024-05-14 16:23:36 +02:00
"core-js-compat": "^3.37.0",
Update npm packages
2023-05-14 10:12:06 +02:00
"esquery": "^1.5.0",
Update npm packages
2022-01-09 10:05:52 +01:00
"indent-string": "^4.0.0",
Update npm packages
2023-05-14 10:12:06 +02:00
"is-builtin-module": "^3.2.1",
Update npm packages
2022-12-25 12:26:23 +01:00
"jsesc": "^3.0.2",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"pluralize": "^8.0.0",
"read-pkg-up": "^7.0.1",
Enable more ESLint `unicorn` plugin rules - `prefer-array-some`, which didn't require any code changes; please find additional details at https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prefer-array-some.md - `prefer-modern-math-apis`, which should be fine given the currently supported browsers; please find additional details at https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prefer-modern-math-apis.md
2023-07-16 09:24:14 +02:00
"regexp-tree": "^0.1.27",
Update npm packages
2023-05-14 10:12:06 +02:00
"regjsparser": "^0.10.0",
Upgrade `eslint-plugin-unicorn` to version 53.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v53.0.0 doesn't indicate any breaking changes that should impact us. Most notably it contains support for ESLint 9, which brings us a step closer towards #17928.
2024-05-14 16:23:36 +02:00
"semver": "^7.6.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"strip-indent": "^3.0.0"
},
"engines": {
Upgrade `eslint-plugin-unicorn` to version 53.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v53.0.0 doesn't indicate any breaking changes that should impact us. Most notably it contains support for ESLint 9, which brings us a step closer towards #17928.
2024-05-14 16:23:36 +02:00
"node": ">=18.18"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
"url": "https://github.com/sindresorhus/eslint-plugin-unicorn?sponsor=1"
},
"peerDependencies": {
Update npm packages
2023-12-23 12:29:51 +01:00
"eslint": ">=8.56.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `eslint-plugin-unicorn` to version 53.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v53.0.0 doesn't indicate any breaking changes that should impact us. Most notably it contains support for ESLint 9, which brings us a step closer towards #17928.
2024-05-14 16:23:36 +02:00
"node_modules/eslint-plugin-unicorn/node_modules/@eslint/eslintrc": {
"version": "3.0.2",
"resolved": "https://registry.npmjs.org/@eslint/eslintrc/-/eslintrc-3.0.2.tgz",
"integrity": "sha512-wV19ZEGEMAC1eHgrS7UQPqsdEiCIbTKTasEfcXAigzoXICcqZSjBZEHlZwNVvKg6UBCjSlos84XiLqsRJnIcIg==",
"dev": true,
"dependencies": {
"ajv": "^6.12.4",
"debug": "^4.3.2",
"espree": "^10.0.1",
"globals": "^14.0.0",
"ignore": "^5.2.0",
"import-fresh": "^3.2.1",
"js-yaml": "^4.1.0",
"minimatch": "^3.1.2",
"strip-json-comments": "^3.1.1"
},
"engines": {
"node": "^18.18.0 || ^20.9.0 || >=21.1.0"
},
"funding": {
"url": "https://opencollective.com/eslint"
}
},
"node_modules/eslint-plugin-unicorn/node_modules/argparse": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
"integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
"dev": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-plugin-unicorn/node_modules/builtin-modules": {
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"version": "3.3.0",
"resolved": "https://registry.npmjs.org/builtin-modules/-/builtin-modules-3.3.0.tgz",
"integrity": "sha512-zhaCDicdLuWN5UbN5IMnFqNMhNfo919sH85y2/ea+5Yg9TsTkeZxpL+JLbp6cgYFS4sRLp3YV4S6yDuqVWHYOw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=6"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Upgrade `eslint-plugin-unicorn` to version 53.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v53.0.0 doesn't indicate any breaking changes that should impact us. Most notably it contains support for ESLint 9, which brings us a step closer towards #17928.
2024-05-14 16:23:36 +02:00
"node_modules/eslint-plugin-unicorn/node_modules/eslint-visitor-keys": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-4.0.0.tgz",
"integrity": "sha512-OtIRv/2GyiF6o/d8K7MYKKbXrOUBIK6SfkIRM4Z0dY3w+LiQ0vy3F57m0Z71bjbyeiWFiHJ8brqnmE6H6/jEuw==",
"dev": true,
"engines": {
"node": "^18.18.0 || ^20.9.0 || >=21.1.0"
},
"funding": {
"url": "https://opencollective.com/eslint"
}
},
"node_modules/eslint-plugin-unicorn/node_modules/espree": {
"version": "10.0.1",
"resolved": "https://registry.npmjs.org/espree/-/espree-10.0.1.tgz",
"integrity": "sha512-MWkrWZbJsL2UwnjxTX3gG8FneachS/Mwg7tdGXce011sJd5b0JG54vat5KHnfSBODZ3Wvzd2WnjxyzsRoVv+ww==",
"dev": true,
"dependencies": {
"acorn": "^8.11.3",
"acorn-jsx": "^5.3.2",
"eslint-visitor-keys": "^4.0.0"
},
"engines": {
"node": "^18.18.0 || ^20.9.0 || >=21.1.0"
},
"funding": {
"url": "https://opencollective.com/eslint"
}
},
"node_modules/eslint-plugin-unicorn/node_modules/globals": {
"version": "14.0.0",
"resolved": "https://registry.npmjs.org/globals/-/globals-14.0.0.tgz",
"integrity": "sha512-oahGvuMGQlPw/ivIYBjVSrWAfWLBeku5tpPE2fOPLi+WHffIWbuh2tCjhyQhTBPMf5E9jDEH4FOmTYgYwbKwtQ==",
"dev": true,
"engines": {
"node": ">=18"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-plugin-unicorn/node_modules/is-builtin-module": {
Update npm packages
2023-05-14 10:12:06 +02:00
"version": "3.2.1",
"resolved": "https://registry.npmjs.org/is-builtin-module/-/is-builtin-module-3.2.1.tgz",
"integrity": "sha512-BSLE3HnV2syZ0FK0iMA/yUGplUeMmNz4AW5fnTunbCIqZi4vG3WjJT9FHMy5D69xmAYBHXQhJdALdpwVxV501A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"builtin-modules": "^3.3.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6"
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `eslint-plugin-unicorn` to version 53.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v53.0.0 doesn't indicate any breaking changes that should impact us. Most notably it contains support for ESLint 9, which brings us a step closer towards #17928.
2024-05-14 16:23:36 +02:00
"node_modules/eslint-plugin-unicorn/node_modules/js-yaml": {
"version": "4.1.0",
"resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz",
"integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==",
"dev": true,
"dependencies": {
"argparse": "^2.0.1"
},
"bin": {
"js-yaml": "bin/js-yaml.js"
}
},
Update npm packages
2022-11-27 10:18:30 +01:00
"node_modules/eslint-plugin-unicorn/node_modules/jsesc": {
"version": "3.0.2",
"resolved": "https://registry.npmjs.org/jsesc/-/jsesc-3.0.2.tgz",
"integrity": "sha512-xKqzzWXDttJuOcawBt4KnKHHIf5oQ/Cxax+0PWFG+DFDgHNAdi+TXECADI+RYiFUMmx8792xsMbbgXj4CwnP4g==",
"dev": true,
"bin": {
"jsesc": "bin/jsesc"
},
"engines": {
"node": ">=6"
}
},
Update npm packages
2023-05-14 10:12:06 +02:00
"node_modules/eslint-plugin-unicorn/node_modules/regjsparser": {
"version": "0.10.0",
"resolved": "https://registry.npmjs.org/regjsparser/-/regjsparser-0.10.0.tgz",
"integrity": "sha512-qx+xQGZVsy55CH0a1hiVwHmqjLryfh7wQyF5HO07XJ9f7dQMY/gPQHhlyDkIzJKC+x2fUCpCcUODUUUFrm7SHA==",
"dev": true,
"dependencies": {
"jsesc": "~0.5.0"
},
"bin": {
"regjsparser": "bin/parser"
}
},
"node_modules/eslint-plugin-unicorn/node_modules/regjsparser/node_modules/jsesc": {
"version": "0.5.0",
"resolved": "https://registry.npmjs.org/jsesc/-/jsesc-0.5.0.tgz",
"integrity": "sha512-uZz5UnB7u4T9LvwmFqXii7pZSouaRPorGs5who1Ip7VO0wxanFvBL7GkM6dTHlgX+jhBApRetaWpnDabOeTcnA==",
"dev": true,
"bin": {
"jsesc": "bin/jsesc"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-plugin-unicorn/node_modules/semver": {
Upgrade `eslint-plugin-unicorn` to version 53.0.0 This is a major version bump, but the changelog at https://github.com/sindresorhus/eslint-plugin-unicorn/releases/tag/v53.0.0 doesn't indicate any breaking changes that should impact us. Most notably it contains support for ESLint 9, which brings us a step closer towards #17928.
2024-05-14 16:23:36 +02:00
"version": "7.6.2",
"resolved": "https://registry.npmjs.org/semver/-/semver-7.6.2.tgz",
"integrity": "sha512-FNAIBWCx9qcRhoHcgcJ0gvU7SN1lYU2ZXuSfl04bSC5OpvDHFyJCjdNHomPXxjQlCBU67YW64PzY7/VIEH7F2w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"bin": {
"semver": "bin/semver.js"
},
"engines": {
"node": ">=10"
}
},
"node_modules/eslint-scope": {
"version": "5.1.1",
"resolved": "https://registry.npmjs.org/eslint-scope/-/eslint-scope-5.1.1.tgz",
"integrity": "sha512-2NxwbF/hZ0KpepYN0cNbo+FN6XoK7GaHlQhgx/hIZl6Va0bF45RQOOwhLIy8lQDbuCiadSLCBnH2CFYquit5bw==",
"dev": true,
"dependencies": {
"esrecurse": "^4.3.0",
"estraverse": "^4.1.1"
},
"engines": {
"node": ">=8.0.0"
}
},
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"node_modules/eslint-utils": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/eslint-utils/-/eslint-utils-2.1.0.tgz",
"integrity": "sha512-w94dQYoauyvlDc43XnGB8lU3Zt713vNChgt4EWwhXAP2XkBvndfxF0AgIqKOOasjPIPzj9JqgwkwbCYD0/V3Zg==",
"dev": true,
"peer": true,
"dependencies": {
"eslint-visitor-keys": "^1.1.0"
},
"engines": {
"node": ">=6"
},
"funding": {
"url": "https://github.com/sponsors/mysticatea"
}
},
"node_modules/eslint-utils/node_modules/eslint-visitor-keys": {
"version": "1.3.0",
"resolved": "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-1.3.0.tgz",
"integrity": "sha512-6J72N8UNa462wa/KFODt/PJ3IU60SDpC3QXC1Hjc1BXXpfL2C9R5+AU7jhe0F6GREqVMh4Juu+NY7xn+6dipUQ==",
"dev": true,
"peer": true,
"engines": {
"node": ">=4"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint-visitor-keys": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "3.4.3",
"resolved": "https://registry.npmjs.org/eslint-visitor-keys/-/eslint-visitor-keys-3.4.3.tgz",
"integrity": "sha512-wpc+LXeiyiisxPlEkUzU6svyS1frIO3Mgxj1fdy7Pm8Ygzguax2N3Fa/D/ag1WqbOprdI+uY6wMUl8/a2G+iag==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Update npm packages
2024-03-17 13:50:21 +01:00
"node": "^12.22.0 || ^14.17.0 || >=16.0.0"
},
"funding": {
"url": "https://opencollective.com/eslint"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/eslint/node_modules/ansi-regex": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
"integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/eslint/node_modules/ansi-styles": {
"version": "4.3.0",
"resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz",
"integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==",
"dev": true,
"dependencies": {
"color-convert": "^2.0.1"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/chalk/ansi-styles?sponsor=1"
}
},
"node_modules/eslint/node_modules/argparse": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
"integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
"dev": true
},
"node_modules/eslint/node_modules/chalk": {
"version": "4.1.2",
"resolved": "https://registry.npmjs.org/chalk/-/chalk-4.1.2.tgz",
"integrity": "sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA==",
"dev": true,
"dependencies": {
"ansi-styles": "^4.1.0",
"supports-color": "^7.1.0"
},
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/chalk/chalk?sponsor=1"
}
},
"node_modules/eslint/node_modules/color-convert": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz",
"integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==",
"dev": true,
"dependencies": {
"color-name": "~1.1.4"
},
"engines": {
Update npm packages
2021-12-26 11:09:29 +01:00
"node": ">=7.0.0"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"node_modules/eslint/node_modules/escape-string-regexp": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-4.0.0.tgz",
"integrity": "sha512-TtpcNJ3XAzx3Gq8sWRzJaVajRs0uVxA2YAkdb1jm2YkPz4G6egUFAyA3n5vtEIZefPk5Wa4UXbKuS5fKkJWdgA==",
"dev": true,
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/eslint/node_modules/eslint-scope": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "7.2.2",
"resolved": "https://registry.npmjs.org/eslint-scope/-/eslint-scope-7.2.2.tgz",
"integrity": "sha512-dOt21O7lTMhDM+X9mB4GX+DZrZtCUJPL/wlcTqxyrx5IvO0IYtILdtrQGQp+8n5S0gwSVmOf9NQrjMOgfQZlIg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"esrecurse": "^4.3.0",
"estraverse": "^5.2.0"
},
"engines": {
"node": "^12.22.0 || ^14.17.0 || >=16.0.0"
Update packages to the most recent versions
2023-04-23 13:48:22 +02:00
},
"funding": {
"url": "https://opencollective.com/eslint"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/eslint/node_modules/estraverse": {
"version": "5.3.0",
"resolved": "https://registry.npmjs.org/estraverse/-/estraverse-5.3.0.tgz",
"integrity": "sha512-MMdARuVEQziNTeJD8DgMqmhwR11BRQ/cBP+pLtYdSTnf3MIO8fFeiINEbX36ZdNlfU/7A9f3gUw49B3oQsvwBA==",
"dev": true,
"engines": {
"node": ">=4.0"
}
},
Update npm packages
2022-08-07 10:20:21 +02:00
"node_modules/eslint/node_modules/find-up": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/find-up/-/find-up-5.0.0.tgz",
"integrity": "sha512-78/PXT1wlLLDgTzDs7sjq9hzz0vXD+zn+7wypEe4fXQxCmdmqfGsEPQxmiCSQI3ajFV91bVSsvNtrJRiW6nGng==",
"dev": true,
"dependencies": {
"locate-path": "^6.0.0",
"path-exists": "^4.0.0"
},
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint/node_modules/glob-parent": {
"version": "6.0.2",
"resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-6.0.2.tgz",
"integrity": "sha512-XxwI8EOhVQgWp6iDL+3b0r86f4d6AX6zSU55HfB4ydCEuXLXc5FcYeOu+nnGftS4TEju/11rt4KJPTMgbfmv4A==",
"dev": true,
"dependencies": {
"is-glob": "^4.0.3"
},
"engines": {
"node": ">=10.13.0"
}
},
Update `globals` to version 14.0.0 This is a major version bump, but the breaking changes don't affect us; please see https://github.com/sindresorhus/globals/releases/tag/v14.0.0.
2024-02-10 18:08:25 +01:00
"node_modules/eslint/node_modules/globals": {
"version": "13.24.0",
"resolved": "https://registry.npmjs.org/globals/-/globals-13.24.0.tgz",
"integrity": "sha512-AhO5QUcj8llrbG09iWhPU2B204J1xnPeL8kQmVorSsy+Sjj1sk8gIyh6cUocGmH4L0UuhAJy+hJMRA4mgA4mFQ==",
"dev": true,
"dependencies": {
"type-fest": "^0.20.2"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint/node_modules/has-flag": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz",
"integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/eslint/node_modules/is-glob": {
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz",
"integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==",
"dev": true,
"dependencies": {
"is-extglob": "^2.1.1"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/eslint/node_modules/js-yaml": {
"version": "4.1.0",
"resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz",
"integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==",
"dev": true,
"dependencies": {
"argparse": "^2.0.1"
},
"bin": {
"js-yaml": "bin/js-yaml.js"
}
},
"node_modules/eslint/node_modules/levn": {
"version": "0.4.1",
"resolved": "https://registry.npmjs.org/levn/-/levn-0.4.1.tgz",
"integrity": "sha512-+bT2uH4E5LGE7h/n3evcS/sQlJXCpIp6ym8OWJ5eV6+67Dsql/LaaT7qJBAt2rzfoa/5QBGBhxDix1dMt2kQKQ==",
"dev": true,
"dependencies": {
"prelude-ls": "^1.2.1",
"type-check": "~0.4.0"
},
"engines": {
"node": ">= 0.8.0"
}
},
Update npm packages
2022-08-07 10:20:21 +02:00
"node_modules/eslint/node_modules/locate-path": {
"version": "6.0.0",
"resolved": "https://registry.npmjs.org/locate-path/-/locate-path-6.0.0.tgz",
"integrity": "sha512-iPZK6eYjbxRu3uB4/WZ3EsEIMJFMqAoopl3R+zuq0UjcAm/MO6KCweDgPfP3elTztoKP3KtnVHxTn2NHBSDVUw==",
"dev": true,
"dependencies": {
"p-locate": "^5.0.0"
},
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint/node_modules/optionator": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"version": "0.9.3",
"resolved": "https://registry.npmjs.org/optionator/-/optionator-0.9.3.tgz",
"integrity": "sha512-JjCoypp+jKn1ttEFExxhetCKeJt9zhAgAve5FXHixTvFDW/5aEktX9bufBKLRRMdU7bNtpLfcGu94B3cdEJgjg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"@aashutoshrathi/word-wrap": "^1.2.3",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"deep-is": "^0.1.3",
"fast-levenshtein": "^2.0.6",
"levn": "^0.4.1",
"prelude-ls": "^1.2.1",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"type-check": "^0.4.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">= 0.8.0"
}
},
Update npm packages
2022-08-07 10:20:21 +02:00
"node_modules/eslint/node_modules/p-limit": {
"version": "3.1.0",
"resolved": "https://registry.npmjs.org/p-limit/-/p-limit-3.1.0.tgz",
"integrity": "sha512-TYOanM3wGwNGsZN2cVTYPArw454xnXj5qmWF1bEoAc4+cU/ol7GVh7odevjp1FNHduHc3KZMcFduxU5Xc6uJRQ==",
"dev": true,
"dependencies": {
"yocto-queue": "^0.1.0"
},
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/eslint/node_modules/p-locate": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/p-locate/-/p-locate-5.0.0.tgz",
"integrity": "sha512-LaNjtRWUBY++zB5nE/NwcaoMylSPk+S+ZHNB1TzdbMJMny6dynpAGt7X/tl/QYq3TIeE6nxHppbo2LGymrG5Pw==",
"dev": true,
"dependencies": {
"p-limit": "^3.0.2"
},
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/eslint/node_modules/path-exists": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/path-exists/-/path-exists-4.0.0.tgz",
"integrity": "sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w==",
"dev": true,
"engines": {
"node": ">=8"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/eslint/node_modules/prelude-ls": {
"version": "1.2.1",
"resolved": "https://registry.npmjs.org/prelude-ls/-/prelude-ls-1.2.1.tgz",
"integrity": "sha512-vkcDPrRZo1QZLbn5RLGPpg/WmIQ65qoWWhcGKf/b5eplkkarX0m9z8ppCat4mlOqUsWpyNuYgO3VRyrYHSzX5g==",
"dev": true,
"engines": {
"node": ">= 0.8.0"
}
},
"node_modules/eslint/node_modules/strip-ansi": {
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
"integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
"dev": true,
"dependencies": {
"ansi-regex": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/eslint/node_modules/supports-color": {
"version": "7.2.0",
"resolved": "https://registry.npmjs.org/supports-color/-/supports-color-7.2.0.tgz",
"integrity": "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==",
"dev": true,
"dependencies": {
"has-flag": "^4.0.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/eslint/node_modules/type-check": {
"version": "0.4.0",
"resolved": "https://registry.npmjs.org/type-check/-/type-check-0.4.0.tgz",
"integrity": "sha512-XleUoc9uwGXqjWwXaUTZAmzMcFZ5858QA2vvx1Ur5xIcixXIP+8LnFDgRplU30us6teqdlskFfu+ae4K79Ooew==",
"dev": true,
"dependencies": {
"prelude-ls": "^1.2.1"
},
"engines": {
"node": ">= 0.8.0"
}
},
Update `globals` to version 14.0.0 This is a major version bump, but the breaking changes don't affect us; please see https://github.com/sindresorhus/globals/releases/tag/v14.0.0.
2024-02-10 18:08:25 +01:00
"node_modules/eslint/node_modules/type-fest": {
"version": "0.20.2",
"resolved": "https://registry.npmjs.org/type-fest/-/type-fest-0.20.2.tgz",
"integrity": "sha512-Ne+eE4r0/iWnpAxD852z3A+N0Bt5RN//NjJwRd2VFHEmrywxf5vsZlh4R6lixl6B+wz/8d+maTSAkN1FIkI3LQ==",
"dev": true,
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/espree": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"version": "9.6.1",
"resolved": "https://registry.npmjs.org/espree/-/espree-9.6.1.tgz",
"integrity": "sha512-oruZaFkjorTpF32kDSI5/75ViwGeZginGGy2NoOSg3Q9bnwlnmDm4HLnkl0RE3n+njDXR037aY1+x58Z/zFdwQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"acorn": "^8.9.0",
Update npm packages
2022-05-15 09:02:57 +02:00
"acorn-jsx": "^5.3.2",
Update npm packages
2023-05-14 10:12:06 +02:00
"eslint-visitor-keys": "^3.4.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": "^12.22.0 || ^14.17.0 || >=16.0.0"
Update npm packages
2022-08-07 10:20:21 +02:00
},
"funding": {
"url": "https://opencollective.com/eslint"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/esprima": {
"version": "4.0.1",
"resolved": "https://registry.npmjs.org/esprima/-/esprima-4.0.1.tgz",
"integrity": "sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A==",
"dev": true,
"bin": {
"esparse": "bin/esparse.js",
"esvalidate": "bin/esvalidate.js"
},
"engines": {
"node": ">=4"
}
},
"node_modules/esquery": {
Update npm packages
2023-03-12 10:27:52 +01:00
"version": "1.5.0",
"resolved": "https://registry.npmjs.org/esquery/-/esquery-1.5.0.tgz",
"integrity": "sha512-YQLXUplAwJgCydQ78IMJywZCceoqk1oH01OERdSAJc/7U2AylwjhSCLDEtqwg811idIS/9fIU5GjG73IgjKMVg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"estraverse": "^5.1.0"
},
"engines": {
"node": ">=0.10"
}
},
"node_modules/esquery/node_modules/estraverse": {
"version": "5.2.0",
"resolved": "https://registry.npmjs.org/estraverse/-/estraverse-5.2.0.tgz",
"integrity": "sha512-BxbNGGNm0RyRYvUdHpIwv9IWzeM9XClbOxwoATuFdOE7ZE6wHL+HQ5T8hoPM+zHvmKzzsEqhgy0GrQ5X13afiQ==",
"dev": true,
"engines": {
"node": ">=4.0"
}
},
"node_modules/esrecurse": {
"version": "4.3.0",
"resolved": "https://registry.npmjs.org/esrecurse/-/esrecurse-4.3.0.tgz",
"integrity": "sha512-KmfKL3b6G+RXvP8N1vr3Tq1kL/oCFgn2NYXEtqP8/L3pKapUA4G8cFVaoF3SU323CD4XypR/ffioHmkti6/Tag==",
"dev": true,
"dependencies": {
"estraverse": "^5.2.0"
},
"engines": {
"node": ">=4.0"
}
},
"node_modules/esrecurse/node_modules/estraverse": {
"version": "5.3.0",
"resolved": "https://registry.npmjs.org/estraverse/-/estraverse-5.3.0.tgz",
"integrity": "sha512-MMdARuVEQziNTeJD8DgMqmhwR11BRQ/cBP+pLtYdSTnf3MIO8fFeiINEbX36ZdNlfU/7A9f3gUw49B3oQsvwBA==",
"dev": true,
"engines": {
"node": ">=4.0"
}
},
"node_modules/estraverse": {
"version": "4.2.0",
"resolved": "https://registry.npmjs.org/estraverse/-/estraverse-4.2.0.tgz",
"integrity": "sha1-De4/7TH81GlhjOc0IJn8GvoL2xM=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/esutils": {
Update npm packages The new major version of `gulp-zip` shouldn't be a problem, given the changes listed in https://github.com/sindresorhus/gulp-zip/releases/tag/v6.0.0
2023-11-04 09:30:39 +01:00
"version": "2.0.3",
"resolved": "https://registry.npmjs.org/esutils/-/esutils-2.0.3.tgz",
"integrity": "sha512-kVscqXk4OCp68SZ0dkgEKVi6/8ij300KBWTJq32P/dYeWTSwK41WyTxalN1eRmA5Z9UU/LX9D7FWSmV9SAYx6g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/events": {
"version": "3.3.0",
"resolved": "https://registry.npmjs.org/events/-/events-3.3.0.tgz",
"integrity": "sha512-mQw+2fkQbALzQ7V0MY0IqdnXNOeTtP4r0lN9z7AAawCXgqea7bDii20AYrIBrFd/Hx0M2Ocz6S111CaFkUcb0Q==",
"dev": true,
"engines": {
"node": ">=0.8.x"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/expand-template": {
"version": "2.0.3",
"resolved": "https://registry.npmjs.org/expand-template/-/expand-template-2.0.3.tgz",
"integrity": "sha512-XYfuKMvj4O35f/pOXLObndIRvyQ+/+6AhODh+OKWj9S9498pHHn/IMszH+gt0fBCRWMNfk1ZSp5x3AifmnI2vg==",
"dev": true,
"engines": {
"node": ">=6"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/expand-tilde": {
"version": "2.0.2",
"resolved": "https://registry.npmjs.org/expand-tilde/-/expand-tilde-2.0.2.tgz",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"integrity": "sha512-A5EmesHW6rfnZ9ysHQjPdJRni0SRar0tjtG5MNtm9n5TUvsYU8oozprtRD4AqHxcZWWlVuAmQo2nWKfN9oyjTw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"homedir-polyfill": "^1.0.1"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/extend": {
"version": "3.0.2",
"resolved": "https://registry.npmjs.org/extend/-/extend-3.0.2.tgz",
"integrity": "sha512-fjquC59cD7CyW6urNXK0FBufkZcoiGG80wTuPujX590cB5Ttln20E2UB4S/WARVqhXffZl2LNgS+gQdPIIim/g==",
"dev": true
},
"node_modules/extend-shallow": {
"version": "3.0.2",
"resolved": "https://registry.npmjs.org/extend-shallow/-/extend-shallow-3.0.2.tgz",
"integrity": "sha1-Jqcarwc7OfshJxcnRhMcJwQCjbg=",
"dev": true,
"dependencies": {
"assign-symbols": "^1.0.0",
"is-extendable": "^1.0.1"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/extend-shallow/node_modules/is-extendable": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/is-extendable/-/is-extendable-1.0.1.tgz",
"integrity": "sha512-arnXMxT1hhoKo9k1LZdmlNyJdDDfy2v0fXjFlmok4+i8ul/6WlbVge9bhM74OpNPQPMGUToDtz+KXa1PneJxOA==",
"dev": true,
"dependencies": {
"is-plain-object": "^2.0.4"
},
"engines": {
"node": ">=0.10.0"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/extract-zip": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/extract-zip/-/extract-zip-2.0.1.tgz",
"integrity": "sha512-GDhU9ntwuKyGXdZBUgTIe+vXnWj0fppUEtMDL0+idd5Sta8TGpHssn/eusA9mrPr9qNDym6SxAYZjNvCn/9RBg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "BSD-2-Clause",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"debug": "^4.1.1",
"get-stream": "^5.1.0",
"yauzl": "^2.10.0"
},
"bin": {
"extract-zip": "cli.js"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">= 10.17.0"
},
"optionalDependencies": {
"@types/yauzl": "^2.9.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update npm packages The new major version of `gulp-zip` shouldn't be a problem, given the changes listed in https://github.com/sindresorhus/gulp-zip/releases/tag/v6.0.0
2023-11-04 09:30:39 +01:00
"node_modules/extract-zip/node_modules/get-stream": {
"version": "5.2.0",
"resolved": "https://registry.npmjs.org/get-stream/-/get-stream-5.2.0.tgz",
"integrity": "sha512-nBF+F1rAZVCu/p7rjzgA+Yb4lfYXrpl7a6VmJrU8wF9I1CKvP/QwPNZHnOlwbTkY6dvtFIzFMSyQXbLoTQPRpA==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages The new major version of `gulp-zip` shouldn't be a problem, given the changes listed in https://github.com/sindresorhus/gulp-zip/releases/tag/v6.0.0
2023-11-04 09:30:39 +01:00
"dependencies": {
"pump": "^3.0.0"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/fancy-log": {
"version": "1.3.3",
"resolved": "https://registry.npmjs.org/fancy-log/-/fancy-log-1.3.3.tgz",
"integrity": "sha512-k9oEhlyc0FrVh25qYuSELjr8oxsCoc4/LEZfg2iJJrfEk/tZL9bCoJE47gqAvI2m/AUjluCS4+3I0eTx8n3AEw==",
"dev": true,
"dependencies": {
"ansi-gray": "^0.1.1",
"color-support": "^1.1.3",
"parse-node-version": "^1.0.0",
"time-stamp": "^1.0.0"
},
"engines": {
"node": ">= 0.10"
}
},
"node_modules/fast-deep-equal": {
"version": "3.1.3",
"resolved": "https://registry.npmjs.org/fast-deep-equal/-/fast-deep-equal-3.1.3.tgz",
"integrity": "sha512-f3qQ9oQy9j2AhBe/H9VC91wLmKBCCU/gDOnKNAYG5hswO7BLKj09Hc5HYNz9cGI++xlpDCIgDaitVs03ATR84Q==",
"dev": true
},
"node_modules/fast-diff": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/fast-diff/-/fast-diff-1.2.0.tgz",
"integrity": "sha512-xJuoT5+L99XlZ8twedaRf6Ax2TgQVxvgZOYoPKqZufmJib0tL2tegPBOZb1pVNgIhlqDlA0eO0c3wBvQcmzx4w==",
"dev": true
},
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"node_modules/fast-fifo": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "1.3.2",
"resolved": "https://registry.npmjs.org/fast-fifo/-/fast-fifo-1.3.2.tgz",
"integrity": "sha512-/d9sfos4yxzpwkDkuN7k2SqFKtYNmCTzgfEpz82x34IM9/zc8KGxQoXg1liNC/izpRM/MBdt44Nmx41ZWqk+FQ==",
"dev": true,
"license": "MIT"
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/fast-glob": {
Update npm packages
2023-12-23 12:29:51 +01:00
"version": "3.3.2",
"resolved": "https://registry.npmjs.org/fast-glob/-/fast-glob-3.3.2.tgz",
"integrity": "sha512-oX2ruAFQwf/Orj8m737Y5adxDQO0LAB7/S5MnxCdTNDd4p6BsyIVsv9JQsATbTSq8KHRpLwIHbVlUNatxd+1Ow==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"@nodelib/fs.stat": "^2.0.2",
"@nodelib/fs.walk": "^1.2.3",
"glob-parent": "^5.1.2",
"merge2": "^1.3.0",
"micromatch": "^4.0.4"
},
"engines": {
Update npm packages
2022-02-06 11:24:14 +01:00
"node": ">=8.6.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/fast-glob/node_modules/braces": {
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"version": "3.0.3",
"resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
"integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"fill-range": "^7.1.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=8"
}
},
"node_modules/fast-glob/node_modules/fill-range": {
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
"integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"to-regex-range": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/fast-glob/node_modules/glob-parent": {
"version": "5.1.2",
"resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz",
"integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==",
"dev": true,
"dependencies": {
"is-glob": "^4.0.1"
},
"engines": {
"node": ">= 6"
}
},
"node_modules/fast-glob/node_modules/is-glob": {
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz",
"integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==",
"dev": true,
"dependencies": {
"is-extglob": "^2.1.1"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/fast-glob/node_modules/is-number": {
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
"integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==",
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=0.12.0"
}
},
"node_modules/fast-glob/node_modules/micromatch": {
"version": "4.0.4",
"resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.4.tgz",
"integrity": "sha512-pRmzw/XUcwXGpD9aI9q/0XOwLNygjETJ8y0ao0wdqprrzDa4YnxLcz7fQRZr8voh8V10kGhABbNcHVk5wHgWwg==",
"dev": true,
"dependencies": {
"braces": "^3.0.1",
"picomatch": "^2.2.3"
},
"engines": {
"node": ">=8.6"
}
},
"node_modules/fast-glob/node_modules/to-regex-range": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
"integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"is-number": "^7.0.0"
},
"engines": {
"node": ">=8.0"
}
},
"node_modules/fast-json-stable-stringify": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/fast-json-stable-stringify/-/fast-json-stable-stringify-2.1.0.tgz",
"integrity": "sha512-lhd/wF+Lk98HZoTCtlVraHtfh5XYijIjalXck7saUtuanSDyLMxnHhSXEDJqHxD7msR8D0uCmqlkwjCV8xvwHw==",
"dev": true
},
"node_modules/fast-levenshtein": {
"version": "2.0.6",
"resolved": "https://registry.npmjs.org/fast-levenshtein/-/fast-levenshtein-2.0.6.tgz",
"integrity": "sha1-PYpcZog6FqMMqGQ+hR8Zuqd5eRc=",
"dev": true
},
"node_modules/fastest-levenshtein": {
Update npm packages
2022-08-21 09:54:06 +02:00
"version": "1.0.16",
"resolved": "https://registry.npmjs.org/fastest-levenshtein/-/fastest-levenshtein-1.0.16.tgz",
"integrity": "sha512-eRnCtTTtGZFpQCwhJiUOuxPQWRXVKYDn0b2PeHfXL6/Zi53SLAzAHfVhVWK2AryC/WH05kGfxhFIPvTF0SXQzg==",
"dev": true,
"engines": {
"node": ">= 4.9.1"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"node_modules/fastq": {
"version": "1.13.0",
"resolved": "https://registry.npmjs.org/fastq/-/fastq-1.13.0.tgz",
"integrity": "sha512-YpkpUnK8od0o1hmeSc7UUs/eB/vIPWJYjKck2QKIzAf71Vm1AAQ3EbuZB3g2JIy+pg+ERD0vqI79KyZiB2e2Nw==",
"dev": true,
"dependencies": {
"reusify": "^1.0.4"
}
},
"node_modules/fd-slicer": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/fd-slicer/-/fd-slicer-1.1.0.tgz",
Update npm packages
2022-10-16 09:09:38 +02:00
"integrity": "sha512-cE1qsB/VwyQozZ+q1dGxR8LBYNZeofhEdUNGSMbQD3Gw2lAzX9Zb3uIU6Ebc/Fmyjo9AWWfnn0AUCHqtevs/8g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"pend": "~1.2.0"
}
},
"node_modules/file-entry-cache": {
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/file-entry-cache/-/file-entry-cache-6.0.1.tgz",
"integrity": "sha512-7Gps/XWymbLk2QLYK4NzpMOrYjMhdIxXuIvy2QBsLE6ljuodKvdkWs/cpyJJ3CVIVpH0Oi1Hvg1ovbMzLdFBBg==",
"dev": true,
"dependencies": {
"flat-cache": "^3.0.4"
},
"engines": {
"node": "^10.12.0 || >=12.0.0"
}
},
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"node_modules/file-uri-to-path": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/file-uri-to-path/-/file-uri-to-path-1.0.0.tgz",
"integrity": "sha512-0Zt+s3L7Vf1biwWZ29aARiVYLx7iMGnEUl9x33fbB/j3jR81u/O2LbqK+Bm1CDSNDKVtJ/YjwY7TUd5SkeLQLw==",
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"dev": true
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/find-cache-dir": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/find-cache-dir/-/find-cache-dir-4.0.0.tgz",
"integrity": "sha512-9ZonPT4ZAK4a+1pUPVPZJapbi7O5qbbJPdYw/NOQWZZbVLdDTYM3A4R9z/DpAM08IDaFGsvPgiGZ82WEwUDWjg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"common-path-prefix": "^3.0.0",
"pkg-dir": "^7.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node": ">=14.16"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/find-up": {
"version": "6.3.0",
"resolved": "https://registry.npmjs.org/find-up/-/find-up-6.3.0.tgz",
"integrity": "sha512-v2ZsoEuVHYy8ZIlYqwPe/39Cy+cFDzp4dXPaxNvkEuouymu+2Jbz0PxpKarJHYJTmv2HWT3O382qY8l4jMWthw==",
"dev": true,
"dependencies": {
"locate-path": "^7.1.0",
"path-exists": "^5.0.0"
},
"engines": {
"node": "^12.20.0 || ^14.13.1 || >=16.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"url": "https://github.com/sponsors/sindresorhus"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/findup-sync": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/findup-sync/-/findup-sync-5.0.0.tgz",
"integrity": "sha512-MzwXju70AuyflbgeOhzvQWAvvQdo1XL0A9bVvlXsYcFEBM87WR4OakL4OfZq+QRmr+duJubio+UtNQCPsVESzQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"detect-file": "^1.0.0",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"is-glob": "^4.0.3",
"micromatch": "^4.0.4",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"resolve-dir": "^1.0.1"
},
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">= 10.13.0"
}
},
"node_modules/findup-sync/node_modules/braces": {
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"version": "3.0.3",
"resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
"integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dependencies": {
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"fill-range": "^7.1.1"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
},
"engines": {
"node": ">=8"
}
},
"node_modules/findup-sync/node_modules/fill-range": {
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
"integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dependencies": {
"to-regex-range": "^5.0.1"
},
"engines": {
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/findup-sync/node_modules/is-glob": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz",
"integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"is-extglob": "^2.1.1"
},
"engines": {
"node": ">=0.10.0"
}
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/findup-sync/node_modules/is-number": {
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
"integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==",
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"engines": {
"node": ">=0.12.0"
}
},
"node_modules/findup-sync/node_modules/micromatch": {
"version": "4.0.5",
"resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.5.tgz",
"integrity": "sha512-DMy+ERcEW2q8Z2Po+WNXuw3c5YaUSFjAO5GsJqfEl7UjvtIuFKO6ZrKvcItdy98dwFI2N1tg3zNIdKaQT+aNdA==",
"dev": true,
"dependencies": {
"braces": "^3.0.2",
"picomatch": "^2.3.1"
},
"engines": {
"node": ">=8.6"
}
},
"node_modules/findup-sync/node_modules/to-regex-range": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
"integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dependencies": {
"is-number": "^7.0.0"
},
"engines": {
"node": ">=8.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/fined": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/fined/-/fined-2.0.0.tgz",
"integrity": "sha512-OFRzsL6ZMHz5s0JrsEr+TpdGNCtrVtnuG3x1yzGNiQHT0yaDnXAj8V/lWcpJVrnoDpcwXcASxAZYbuXda2Y82A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"expand-tilde": "^2.0.2",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"is-plain-object": "^5.0.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"object.defaults": "^1.1.0",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"object.pick": "^1.3.0",
"parse-filepath": "^1.0.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">= 10.13.0"
}
},
"node_modules/fined/node_modules/is-plain-object": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/is-plain-object/-/is-plain-object-5.0.0.tgz",
"integrity": "sha512-VRSzKkbMm5jMDoKLbltAkFQ5Qr7VDiTFGXxYFXXowVj387GeGNOCsOH6Msy00SGZ3Fp84b1Naa1psqgcCIEP5Q==",
"dev": true,
"engines": {
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/flagged-respawn": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/flagged-respawn/-/flagged-respawn-2.0.0.tgz",
"integrity": "sha512-Gq/a6YCi8zexmGHMuJwahTGzXlAZAOsbCVKduWXC6TlLCjjFRlExMJc4GC2NYPYZ0r/brw9P7CpRgQmlPVeOoA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/flat-cache": {
Update npm packages
2023-12-23 12:29:51 +01:00
"version": "3.2.0",
"resolved": "https://registry.npmjs.org/flat-cache/-/flat-cache-3.2.0.tgz",
"integrity": "sha512-CYcENa+FtcUKLmhhqyctpclsq7QF38pKjZHsGNiSQF5r4FtoKDWabFDl3hzaEQMvT1LHEysw5twgLvpYYb4vbw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"flatted": "^3.2.9",
"keyv": "^4.5.3",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"rimraf": "^3.0.2"
},
"engines": {
Update npm packages
2023-12-23 12:29:51 +01:00
"node": "^10.12.0 || >=12.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/flatted": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"version": "3.3.1",
"resolved": "https://registry.npmjs.org/flatted/-/flatted-3.3.1.tgz",
"integrity": "sha512-X8cqMLLie7KsNUDSdzeN8FYK9rEt4Dt67OsG/DNGnYTSDBG4uFAJFBnUeiV+zCVAvwFy56IjM9sH51jVaEhNxw==",
"dev": true,
"license": "ISC"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/follow-redirects": {
Bump follow-redirects from 1.15.4 to 1.15.6 Bumps [follow-redirects](https://github.com/follow-redirects/follow-redirects) from 1.15.4 to 1.15.6. - [Release notes](https://github.com/follow-redirects/follow-redirects/releases) - [Commits](https://github.com/follow-redirects/follow-redirects/compare/v1.15.4...v1.15.6) --- updated-dependencies: - dependency-name: follow-redirects dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
2024-03-16 23:00:41 +00:00
"version": "1.15.6",
"resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.15.6.tgz",
"integrity": "sha512-wWN62YITEaOpSK584EZXJafH1AGpO8RVgElfkuXbTOrPX4fIfOyEpW/CsiNd8JdYrAoOvafRTOEnvsO++qCqFA==",
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"dev": true,
"funding": [
{
"type": "individual",
"url": "https://github.com/sponsors/RubenVerborgh"
}
],
"engines": {
"node": ">=4.0"
},
"peerDependenciesMeta": {
"debug": {
"optional": true
}
}
},
Update npm packages
2023-01-15 10:34:56 +01:00
"node_modules/for-each": {
"version": "0.3.3",
"resolved": "https://registry.npmjs.org/for-each/-/for-each-0.3.3.tgz",
"integrity": "sha512-jqYfLp7mo9vIyQf8ykW2v7A+2N4QjeCeI5+Dz9XraiO1ign81wjiH7Fb9vSOWvQfNtmSa4H2RoQTrrXivdUZmw==",
"dev": true,
"dependencies": {
"is-callable": "^1.1.3"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/for-in": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/for-in/-/for-in-1.0.2.tgz",
"integrity": "sha1-gQaNKVqBQuwKxybG4iAMMPttXoA=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/for-own": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/for-own/-/for-own-1.0.0.tgz",
"integrity": "sha1-xjMy9BXO3EsE2/5wz4NklMU8tEs=",
"dev": true,
"dependencies": {
"for-in": "^1.0.1"
},
"engines": {
"node": ">=0.10.0"
}
},
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node_modules/foreground-child": {
"version": "3.1.1",
"resolved": "https://registry.npmjs.org/foreground-child/-/foreground-child-3.1.1.tgz",
"integrity": "sha512-TMKDUnIte6bfb5nWv7V/caI169OHgvwjb7V4WkeUvbQQdjr5rWKqHFiKWb/fcOwB+CzBT+qbWjvj+DVwRskpIg==",
"dev": true,
"dependencies": {
"cross-spawn": "^7.0.0",
"signal-exit": "^4.0.1"
},
"engines": {
"node": ">=14"
},
"funding": {
"url": "https://github.com/sponsors/isaacs"
}
},
"node_modules/foreground-child/node_modules/signal-exit": {
"version": "4.0.2",
"resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-4.0.2.tgz",
"integrity": "sha512-MY2/qGx4enyjprQnFaZsHib3Yadh3IXyV2C321GY0pjGfVBu4un0uDJkwgdxqO+Rdx8JMT8IfJIRwbYVz3Ob3Q==",
"dev": true,
"engines": {
"node": ">=14"
},
"funding": {
"url": "https://github.com/sponsors/isaacs"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/form-data": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/form-data/-/form-data-4.0.0.tgz",
"integrity": "sha512-ETEklSGi5t0QMZuiXoA/Q6vcnxcLQP5vdugSpuAyi6SVGi2clPPp+xgEhuMaHC+zGgn31Kd235W35f7Hykkaww==",
"dev": true,
"dependencies": {
"asynckit": "^0.4.0",
"combined-stream": "^1.0.8",
"mime-types": "^2.1.12"
},
"engines": {
"node": ">= 6"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/fraction.js": {
Update npm packages
2024-01-20 09:40:33 +01:00
"version": "4.3.7",
"resolved": "https://registry.npmjs.org/fraction.js/-/fraction.js-4.3.7.tgz",
"integrity": "sha512-ZsDfxO51wGAXREY55a7la9LScWpwv9RxIrYABrlvOFBlH/ShPnrtsXeuUIfXKKOVicNxQ+o8JTbJvjS4M89yew==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": "*"
},
"funding": {
"type": "patreon",
Update npm packages
2023-09-24 11:03:19 +02:00
"url": "https://github.com/sponsors/rawify"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/fs-constants": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/fs-constants/-/fs-constants-1.0.0.tgz",
"integrity": "sha512-y6OAwoSIf7FyjMIv94u+b5rdheZEjzR63GTyZJm5qh4Bi+2YgwLCcI/fPFZkL5PSixOt6ZNKm+w+Hfp/Bciwow==",
"dev": true
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/fs-extra": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"version": "11.2.0",
"resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-11.2.0.tgz",
"integrity": "sha512-PmDi3uwK5nFuXh7XDTlVnS17xJS7vW36is2+w3xcv8SVxiB4NyATf4ctkVY5bkSjX0Y4nbvZCq1/EjtEyr9ktw==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"graceful-fs": "^4.2.0",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"jsonfile": "^6.0.1",
"universalify": "^2.0.0"
Update npm packages
2023-07-23 09:49:53 +02:00
},
"engines": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"node": ">=14.14"
Update npm packages
2023-07-23 09:49:53 +02:00
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/fs-minipass": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/fs-minipass/-/fs-minipass-2.1.0.tgz",
"integrity": "sha512-V/JgOLFCS+R6Vcq0slCuaeWEdNC3ouDlJMNIsacH2VtALiu9mV4LPrHc5cDl8k5aw6J8jwgWWpiTo5RYhmIzvg==",
"dev": true,
"dependencies": {
"minipass": "^3.0.0"
},
"engines": {
"node": ">= 8"
}
},
"node_modules/fs-mkdirp-stream": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/fs-mkdirp-stream/-/fs-mkdirp-stream-2.0.1.tgz",
"integrity": "sha512-UTOY+59K6IA94tec8Wjqm0FSh5OVudGNB0NL/P6fB3HiE3bYOY3VYBGijsnOHNkQSwC1FKkU77pmq7xp9CskLw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"graceful-fs": "^4.2.8",
"streamx": "^2.12.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/fs.realpath": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz",
"integrity": "sha1-FQStJSMVjKpA20onh8sBQRmU6k8=",
"dev": true
},
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"node_modules/fsevents": {
"version": "2.3.3",
"resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz",
"integrity": "sha512-5xoDfX+fL7faATnagmWPpbFtwh/R77WmMMqqHGS65C3vvB0YHrgF+B1YmZ3441tMj5n63k0212XNoJwzlhffQw==",
"dev": true,
"hasInstallScript": true,
"optional": true,
"os": [
"darwin"
],
"engines": {
"node": "^8.16.0 || ^10.6.0 || >=11.0.0"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/function-bind": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"version": "1.1.2",
"resolved": "https://registry.npmjs.org/function-bind/-/function-bind-1.1.2.tgz",
"integrity": "sha512-7XHNxH7qX9xG5mIwxkhumTox/MIRNcOgDrxWsMt2pAr23WHp6MrRlN7FBSFpCpr+oVO0F744iUgR82nJMfG2SA==",
"dev": true,
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/function.prototype.name": {
"version": "1.1.5",
"resolved": "https://registry.npmjs.org/function.prototype.name/-/function.prototype.name-1.1.5.tgz",
"integrity": "sha512-uN7m/BzVKQnCUF/iW8jYea67v++2u7m5UgENbHRtdDVclOUP+FMPlCNdmk0h/ysGyo2tavMJEDqJAkJdRa1vMA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dependencies": {
"call-bind": "^1.0.2",
"define-properties": "^1.1.3",
"es-abstract": "^1.19.0",
"functions-have-names": "^1.2.2"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/functions-have-names": {
"version": "1.2.3",
"resolved": "https://registry.npmjs.org/functions-have-names/-/functions-have-names-1.2.3.tgz",
"integrity": "sha512-xckBUXyTIqT97tq2x2AMb+g163b5JFysYk0x4qxNFwbfQkmNZoiRHb6sPzI9/QV33WeuvVYBUIiD4NzNIyqaRQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/gauge": {
"version": "2.7.4",
"resolved": "https://registry.npmjs.org/gauge/-/gauge-2.7.4.tgz",
"integrity": "sha1-LANAXHU4w51+s3sxcCLjJfsBi/c=",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"aproba": "^1.0.3",
"console-control-strings": "^1.0.0",
"has-unicode": "^2.0.0",
"object-assign": "^4.1.0",
"signal-exit": "^3.0.0",
"string-width": "^1.0.1",
"strip-ansi": "^3.0.1",
"wide-align": "^1.1.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/gensync": {
"version": "1.0.0-beta.2",
"resolved": "https://registry.npmjs.org/gensync/-/gensync-1.0.0-beta.2.tgz",
"integrity": "sha512-3hN7NaskYvMDLQY55gnW3NQ+mesEAepTqlg+VEbj7zzqEMBVNhzcGYYeqFo/TlYz6eQiFcp1HcsCZO+nGgS8zg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=6.9.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/get-caller-file": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "2.0.5",
"resolved": "https://registry.npmjs.org/get-caller-file/-/get-caller-file-2.0.5.tgz",
"integrity": "sha512-DyFP3BM/3YHTQOCUL/w0OZHR0lpKeGrxotcHWcqNEdnltqFwXVfhEBQ94eIo34AfQpo0rGki4cyIiftY06h2Fg==",
"dev": true,
"engines": {
"node": "6.* || 8.* || >= 10.*"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/get-intrinsic": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "1.2.1",
"resolved": "https://registry.npmjs.org/get-intrinsic/-/get-intrinsic-1.2.1.tgz",
"integrity": "sha512-2DcsyfABl+gVHEfCOaTrWgyt+tb6MSEGmKq+kI5HwLbIYgjgmMcV8KQ41uaKz1xxUcn9tJtgFbQUEVcEbd0FYw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"function-bind": "^1.1.1",
"has": "^1.0.3",
Update npm packages
2023-08-06 09:22:20 +02:00
"has-proto": "^1.0.1",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"has-symbols": "^1.0.3"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/get-stream": {
Update npm packages The new major version of `gulp-zip` shouldn't be a problem, given the changes listed in https://github.com/sindresorhus/gulp-zip/releases/tag/v6.0.0
2023-11-04 09:30:39 +01:00
"version": "8.0.1",
"resolved": "https://registry.npmjs.org/get-stream/-/get-stream-8.0.1.tgz",
"integrity": "sha512-VaUJspBffn/LMCJVoMvSAdmscJyS1auj5Zulnn5UoYcY531UWmdwhRWkcGKnGU93m5HSXP9LP2usOryrBtQowA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Update npm packages The new major version of `gulp-zip` shouldn't be a problem, given the changes listed in https://github.com/sindresorhus/gulp-zip/releases/tag/v6.0.0
2023-11-04 09:30:39 +01:00
"node": ">=16"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/get-symbol-description": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/get-symbol-description/-/get-symbol-description-1.0.0.tgz",
"integrity": "sha512-2EmdH1YvIQiZpltCNgkuiUnyukzxM/R6NDJX31Ke3BG1Nq5b0S2PhX59UKi9vZpPDQVdqn+1IcaAwnzTT5vCjw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dependencies": {
"call-bind": "^1.0.2",
"get-intrinsic": "^1.1.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/get-uri": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"version": "6.0.3",
"resolved": "https://registry.npmjs.org/get-uri/-/get-uri-6.0.3.tgz",
"integrity": "sha512-BzUrJBS9EcUb4cFol8r4W3v1cPsSyajLSthNkz5BxbpDcHN5tIrM10E2eNvfnvBn3DaT3DUgx0OpsBKkaOpanw==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"basic-ftp": "^5.0.2",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"data-uri-to-buffer": "^6.0.2",
Update npm packages
2023-07-23 09:49:53 +02:00
"debug": "^4.3.4",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"fs-extra": "^11.2.0"
Update npm packages
2023-07-23 09:49:53 +02:00
},
"engines": {
"node": ">= 14"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/github-from-package": {
"version": "0.0.0",
"resolved": "https://registry.npmjs.org/github-from-package/-/github-from-package-0.0.0.tgz",
"integrity": "sha512-SyHy3T1v2NUXn29OsWdxmK6RwHD+vkj3v8en8AOBZ1wBQ/hCAQ5bAQTD02kW4W9tUp/3Qh6J8r9EvntiyCmOOw==",
"dev": true
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/glob-stream": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "8.0.2",
"resolved": "https://registry.npmjs.org/glob-stream/-/glob-stream-8.0.2.tgz",
"integrity": "sha512-R8z6eTB55t3QeZMmU1C+Gv+t5UnNRkA55c5yo67fAVfxODxieTwsjNG7utxS/73NdP1NbDgCrhVEg2h00y4fFw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"@gulpjs/to-absolute-glob": "^4.0.0",
"anymatch": "^3.1.3",
"fastq": "^1.13.0",
"glob-parent": "^6.0.2",
"is-glob": "^4.0.3",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"is-negated-glob": "^1.0.0",
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"normalize-path": "^3.0.0",
"streamx": "^2.12.5"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/glob-stream/node_modules/anymatch": {
"version": "3.1.3",
"resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.3.tgz",
"integrity": "sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==",
"dev": true,
"license": "ISC",
"dependencies": {
"normalize-path": "^3.0.0",
"picomatch": "^2.0.4"
},
"engines": {
"node": ">= 8"
}
},
"node_modules/glob-stream/node_modules/glob-parent": {
"version": "6.0.2",
"resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-6.0.2.tgz",
"integrity": "sha512-XxwI8EOhVQgWp6iDL+3b0r86f4d6AX6zSU55HfB4ydCEuXLXc5FcYeOu+nnGftS4TEju/11rt4KJPTMgbfmv4A==",
"dev": true,
"license": "ISC",
"dependencies": {
"is-glob": "^4.0.3"
},
"engines": {
"node": ">=10.13.0"
}
},
"node_modules/glob-stream/node_modules/is-glob": {
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz",
"integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==",
Remove the `merge-stream` dependency in favor of the `ordered-read-streams` dependency The `merge-stream` dependency is no longer maintained and doesn't work in combination with Gulp 5 anymore (for more information refer to https://github.com/gulpjs/gulp/issues/2802#issuecomment-2094130656). Fortunately the Gulp team maintains a drop-in replacement dependency called `ordered-read-streams` with the same API as `merge-stream`. Indeed, running all affected Gulp targets and comparing build artifacts with `diff -r <old> <new>` confirms that no unexpected changes are made. Fixes a part of #17922.
2024-05-22 14:11:58 +02:00
"dev": true,
"license": "MIT",
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"is-extglob": "^2.1.1"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/glob-stream/node_modules/normalize-path": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz",
"integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==",
"dev": true,
"license": "MIT",
"engines": {
"node": ">=0.10.0"
Remove the `merge-stream` dependency in favor of the `ordered-read-streams` dependency The `merge-stream` dependency is no longer maintained and doesn't work in combination with Gulp 5 anymore (for more information refer to https://github.com/gulpjs/gulp/issues/2802#issuecomment-2094130656). Fortunately the Gulp team maintains a drop-in replacement dependency called `ordered-read-streams` with the same API as `merge-stream`. Indeed, running all affected Gulp targets and comparing build artifacts with `diff -r <old> <new>` confirms that no unexpected changes are made. Fixes a part of #17922.
2024-05-22 14:11:58 +02:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/glob-to-regexp": {
"version": "0.4.1",
"resolved": "https://registry.npmjs.org/glob-to-regexp/-/glob-to-regexp-0.4.1.tgz",
"integrity": "sha512-lkX1HJXwyMcprw/5YUZc2s7DrpAiHB21/V+E1rHUrVNokkvB6bqMzT0VfV6/86ZNabt1k14YOIaT7nDvOX3Iiw==",
"dev": true
},
"node_modules/glob-watcher": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "6.0.0",
"resolved": "https://registry.npmjs.org/glob-watcher/-/glob-watcher-6.0.0.tgz",
"integrity": "sha512-wGM28Ehmcnk2NqRORXFOTOR064L4imSw3EeOqU5bIwUf62eXGwg89WivH6VMahL8zlQHeodzvHpXplrqzrz3Nw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
"dependencies": {
"async-done": "^2.0.0",
"chokidar": "^3.5.3"
},
"engines": {
"node": ">= 10.13.0"
}
},
"node_modules/glob-watcher/node_modules/anymatch": {
"version": "3.1.3",
"resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.3.tgz",
"integrity": "sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==",
"dev": true,
"license": "ISC",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"normalize-path": "^3.0.0",
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"picomatch": "^2.0.4"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">= 8"
}
},
"node_modules/glob-watcher/node_modules/binary-extensions": {
"version": "2.3.0",
"resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.3.0.tgz",
"integrity": "sha512-Ceh+7ox5qe7LJuLHoY0feh3pHuUDHAcRUeyL2VYghZwfpkNIy/+8Ocg0a3UuSoYzavmylwuLWQOf3hl0jjMMIw==",
"dev": true,
"license": "MIT",
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/glob-watcher/node_modules/braces": {
"version": "3.0.3",
"resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
"integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
"dev": true,
"license": "MIT",
"dependencies": {
"fill-range": "^7.1.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/glob-watcher/node_modules/chokidar": {
"version": "3.6.0",
"resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.6.0.tgz",
"integrity": "sha512-7VT13fmjotKpGipCW9JEQAusEPE+Ei8nl6/g4FBAmIm0GOOLMua9NDDo/DWp0ZAxCr3cPq5ZpBqmPAQgDda2Pw==",
"dev": true,
"license": "MIT",
"dependencies": {
"anymatch": "~3.1.2",
"braces": "~3.0.2",
"glob-parent": "~5.1.2",
"is-binary-path": "~2.1.0",
"is-glob": "~4.0.1",
"normalize-path": "~3.0.0",
"readdirp": "~3.6.0"
},
"engines": {
"node": ">= 8.10.0"
},
"funding": {
"url": "https://paulmillr.com/funding/"
},
"optionalDependencies": {
"fsevents": "~2.3.2"
}
},
"node_modules/glob-watcher/node_modules/fill-range": {
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
"integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
"dev": true,
"license": "MIT",
"dependencies": {
"to-regex-range": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/glob-watcher/node_modules/glob-parent": {
"version": "5.1.2",
"resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz",
"integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==",
"dev": true,
"license": "ISC",
"dependencies": {
"is-glob": "^4.0.1"
},
"engines": {
"node": ">= 6"
}
},
"node_modules/glob-watcher/node_modules/is-binary-path": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz",
"integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==",
"dev": true,
"license": "MIT",
"dependencies": {
"binary-extensions": "^2.0.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/glob-watcher/node_modules/is-glob": {
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz",
"integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==",
"dev": true,
"license": "MIT",
"dependencies": {
"is-extglob": "^2.1.1"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/glob-watcher/node_modules/is-number": {
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
"integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==",
"dev": true,
"license": "MIT",
"engines": {
"node": ">=0.12.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/glob-watcher/node_modules/normalize-path": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz",
"integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/glob-watcher/node_modules/readdirp": {
"version": "3.6.0",
"resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.6.0.tgz",
"integrity": "sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==",
"dev": true,
"license": "MIT",
"dependencies": {
"picomatch": "^2.2.1"
},
"engines": {
"node": ">=8.10.0"
}
},
"node_modules/glob-watcher/node_modules/to-regex-range": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
"integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
"dev": true,
"license": "MIT",
"dependencies": {
"is-number": "^7.0.0"
},
"engines": {
"node": ">=8.0"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/global-modules": {
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"version": "1.0.0",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"resolved": "https://registry.npmjs.org/global-modules/-/global-modules-1.0.0.tgz",
"integrity": "sha512-sKzpEkf11GpOFuw0Zzjzmt4B4UZwjOcG757PPvrfhxcLFbq0wpsgpOqxpxtxFiCG4DtG93M6XRVbF2oGdev7bg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"global-prefix": "^1.0.1",
"is-windows": "^1.0.1",
"resolve-dir": "^1.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=0.10.0"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/global-prefix": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/global-prefix/-/global-prefix-1.0.2.tgz",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"integrity": "sha512-5lsx1NUDHtSjfg0eHlmYvZKv8/nVqX4ckFbM+FrGcQ+04KWcWFo9P5MxPZYSzUvyzmdTbI7Eix8Q4IbELDqzKg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"expand-tilde": "^2.0.2",
"homedir-polyfill": "^1.0.1",
"ini": "^1.3.4",
"is-windows": "^1.0.1",
"which": "^1.2.14"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/globals": {
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"version": "15.8.0",
"resolved": "https://registry.npmjs.org/globals/-/globals-15.8.0.tgz",
"integrity": "sha512-VZAJ4cewHTExBWDHR6yptdIBlx9YSSZuwojj9Nt5mBRXQzrKakDsVKQ1J63sklLvzAJm0X5+RpO4i3Y2hcOnFw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-23 15:59:27 +02:00
"license": "MIT",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
Update `globals` to version 14.0.0 This is a major version bump, but the breaking changes don't affect us; please see https://github.com/sindresorhus/globals/releases/tag/v14.0.0.
2024-02-10 18:08:25 +01:00
"node": ">=18"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/globalthis": {
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/globalthis/-/globalthis-1.0.3.tgz",
"integrity": "sha512-sFdI5LyBiNTHjRd7cGPWapiHWMOXKyuBNX/cWJ3NfzrZQVa8GI/8cofCl74AOVqq9W5kNmguTIzJ/1s2gyI9wA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"define-properties": "^1.1.3"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/globby": {
"version": "11.1.0",
"resolved": "https://registry.npmjs.org/globby/-/globby-11.1.0.tgz",
"integrity": "sha512-jhIXaOzy1sb8IyocaruWSn1TjmnBVs8Ayhcy83rmxNJ8q2uWKCAj3CnJY+KpGSXCueAPc0i05kVvVKtP1t9S3g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"array-union": "^2.1.0",
"dir-glob": "^3.0.1",
"fast-glob": "^3.2.9",
"ignore": "^5.2.0",
"merge2": "^1.4.1",
"slash": "^3.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/globjoin": {
"version": "0.1.4",
"resolved": "https://registry.npmjs.org/globjoin/-/globjoin-0.1.4.tgz",
"integrity": "sha1-L0SUrIkZ43Z8XLtpHp9GMyQoXUM=",
"dev": true
},
"node_modules/glogg": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "2.2.0",
"resolved": "https://registry.npmjs.org/glogg/-/glogg-2.2.0.tgz",
"integrity": "sha512-eWv1ds/zAlz+M1ioHsyKJomfY7jbDDPpwSkv14KQj89bycx1nvK5/2Cj/T9g7kzJcX5Bc7Yv22FjfBZS/jl94A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"sparkles": "^2.1.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/gopd": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/gopd/-/gopd-1.0.1.tgz",
"integrity": "sha512-d65bNlIadxvpb/A2abVdlqKqV563juRnZ1Wtk6s1sIR8uNsXR70xqIzVqxVf1eTqDunwT2MkczEeaezCKTZhwA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"get-intrinsic": "^1.1.3"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/graceful-fs": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"version": "4.2.11",
"resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.11.tgz",
"integrity": "sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dev": true
},
Update npm packages
2023-05-28 09:39:34 +02:00
"node_modules/graphemer": {
"version": "1.4.0",
"resolved": "https://registry.npmjs.org/graphemer/-/graphemer-1.4.0.tgz",
"integrity": "sha512-EtKwoO6kxCL9WO5xipiHTZlSzBm7WLT627TqC/uVRd0HKmq8NXyebnNYxDoBi7wt8eTWrUrKXCOVaFq9x1kgag==",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dev": true
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/gray-matter": {
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/gray-matter/-/gray-matter-4.0.3.tgz",
"integrity": "sha512-5v6yZd4JK3eMI3FqqCouswVqwugaA9r4dNZB1wwcmrD02QkV5H0y7XBQW8QwQqEaZY1pM9aqORSORhJRdNK44Q==",
"dev": true,
"license": "MIT",
"dependencies": {
"js-yaml": "^3.13.1",
"kind-of": "^6.0.2",
"section-matter": "^1.0.0",
"strip-bom-string": "^1.0.0"
},
"engines": {
"node": ">=6.0"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/gulp": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/gulp/-/gulp-5.0.0.tgz",
"integrity": "sha512-S8Z8066SSileaYw1S2N1I64IUc/myI2bqe2ihOBzO6+nKpvNSg7ZcWJt/AwF8LC/NVN+/QZ560Cb/5OPsyhkhg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"glob-watcher": "^6.0.0",
"gulp-cli": "^3.0.0",
"undertaker": "^2.0.0",
"vinyl-fs": "^4.0.0"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
"bin": {
"gulp": "bin/gulp.js"
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update `gulp-cli` to 2.3.0 and explicitly add it as a dependency
2024-01-10 14:59:32 +01:00
"node_modules/gulp-cli": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/gulp-cli/-/gulp-cli-3.0.0.tgz",
"integrity": "sha512-RtMIitkT8DEMZZygHK2vEuLPqLPAFB4sntSxg4NoDta7ciwGZ18l7JuhCTiS5deOJi2IoK0btE+hs6R4sfj7AA==",
"dev": true,
"dependencies": {
"@gulpjs/messages": "^1.1.0",
"chalk": "^4.1.2",
"copy-props": "^4.0.0",
"gulplog": "^2.2.0",
"interpret": "^3.1.1",
"liftoff": "^5.0.0",
"mute-stdout": "^2.0.0",
"replace-homedir": "^2.0.0",
"semver-greatest-satisfied-range": "^2.0.0",
"string-width": "^4.2.3",
"v8flags": "^4.0.0",
"yargs": "^16.2.0"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"bin": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"gulp": "bin/gulp.js"
},
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">=10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/gulp-cli/node_modules/ansi-regex": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
"integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">=8"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/gulp-cli/node_modules/ansi-styles": {
"version": "4.3.0",
"resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz",
"integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"color-convert": "^2.0.1"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/chalk/ansi-styles?sponsor=1"
Update `gulp-cli` to 2.3.0 and explicitly add it as a dependency
2024-01-10 14:59:32 +01:00
}
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/gulp-cli/node_modules/chalk": {
"version": "4.1.2",
"resolved": "https://registry.npmjs.org/chalk/-/chalk-4.1.2.tgz",
"integrity": "sha512-oKnbhFyRIXpUuez8iBMmyEa4nbj4IOQyuhc/wy9kY7/WVPcwIO9VA668Pu8RkO7+0G76SLROeyw9CpQ061i4mA==",
Update `gulp-cli` to 2.3.0 and explicitly add it as a dependency
2024-01-10 14:59:32 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"ansi-styles": "^4.1.0",
"supports-color": "^7.1.0"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">=10"
},
"funding": {
"url": "https://github.com/chalk/chalk?sponsor=1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/gulp-cli/node_modules/cliui": {
"version": "7.0.4",
"resolved": "https://registry.npmjs.org/cliui/-/cliui-7.0.4.tgz",
"integrity": "sha512-OcRE68cOsVMXp1Yvonl/fzkQOyjLSu/8bhPDfQt0e0/Eb283TKP20Fs2MqoPsr9SwA595rRCA+QMzYc9nBP+JQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"string-width": "^4.2.0",
"strip-ansi": "^6.0.0",
"wrap-ansi": "^7.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/gulp-cli/node_modules/color-convert": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz",
"integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"color-name": "~1.1.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">=7.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/gulp-cli/node_modules/has-flag": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz",
"integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/gulp-cli/node_modules/is-fullwidth-code-point": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
"integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/gulp-cli/node_modules/string-width": {
"version": "4.2.3",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
"integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"emoji-regex": "^8.0.0",
"is-fullwidth-code-point": "^3.0.0",
"strip-ansi": "^6.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/gulp-cli/node_modules/strip-ansi": {
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
"integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
"dev": true,
"dependencies": {
"ansi-regex": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/gulp-cli/node_modules/supports-color": {
"version": "7.2.0",
"resolved": "https://registry.npmjs.org/supports-color/-/supports-color-7.2.0.tgz",
"integrity": "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==",
"dev": true,
"dependencies": {
"has-flag": "^4.0.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/gulp-cli/node_modules/yargs": {
"version": "16.2.0",
"resolved": "https://registry.npmjs.org/yargs/-/yargs-16.2.0.tgz",
"integrity": "sha512-D1mvvtDG0L5ft/jGWkLpG1+m0eQxOfaBvTNELraWj22wSVUMWxZUvYgJYcKh6jGGIkJFhH4IZPQhR4TKpc8mBw==",
"dev": true,
"dependencies": {
"cliui": "^7.0.2",
"escalade": "^3.1.1",
"get-caller-file": "^2.0.5",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"require-directory": "^2.1.1",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"string-width": "^4.2.0",
"y18n": "^5.0.5",
"yargs-parser": "^20.2.2"
},
"engines": {
"node": ">=10"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update `gulp-cli` to 2.3.0 and explicitly add it as a dependency
2024-01-10 14:59:32 +01:00
"node_modules/gulp-cli/node_modules/yargs-parser": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "20.2.9",
"resolved": "https://registry.npmjs.org/yargs-parser/-/yargs-parser-20.2.9.tgz",
"integrity": "sha512-y11nGElTIV+CT3Zv9t7VKl+Q3hTQoT9a1Qzezhhl6Rp21gJ/IVTW7Z3y9EWXhuUBC2Shnf+DX0antecpAwSP8w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"engines": {
"node": ">=10"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update `gulp-cli` to 2.3.0 and explicitly add it as a dependency
2024-01-10 14:59:32 +01:00
"node_modules/gulp-plugin-extras": {
"version": "0.3.0",
"resolved": "https://registry.npmjs.org/gulp-plugin-extras/-/gulp-plugin-extras-0.3.0.tgz",
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"integrity": "sha512-I/kOBSpo61QsGQZcqozZYEnDseKvpudUafVVWDLYgBFAUJ37kW5R8Sjw9cMYzpGyPUfEYOeoY4p+dkfLqgyJUQ==",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"@types/vinyl": "^2.0.9",
"chalk": "^5.3.0",
"easy-transform-stream": "^1.0.1"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=18"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/gulp-plugin-extras/node_modules/chalk": {
"version": "5.3.0",
"resolved": "https://registry.npmjs.org/chalk/-/chalk-5.3.0.tgz",
"integrity": "sha512-dLitG79d+GV1Nb/VYcCDFivJeK1hiukt9QjRNVOsUtTy1rR1YJsmpGGTZ3qJos+uw7WmWF4wUwBd9jxjocFC2w==",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dev": true,
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": "^12.17.0 || ^14.13 || >=16.0.0"
},
"funding": {
"url": "https://github.com/chalk/chalk?sponsor=1"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/gulp-postcss": {
"version": "10.0.0",
"resolved": "https://registry.npmjs.org/gulp-postcss/-/gulp-postcss-10.0.0.tgz",
"integrity": "sha512-z1RF2RJEX/BvFsKN11PXai8lRmihZTiHnlJf7Zu8uHaA/Q7Om4IeN8z1NtMAW5OiLwUY02H0DIFl9tHl0CNSgA==",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"fancy-log": "^2.0.0",
"plugin-error": "^2.0.1",
"postcss-load-config": "^5.0.0",
"vinyl-sourcemaps-apply": "^0.2.1"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=18"
},
"peerDependencies": {
"postcss": "^8.0.0"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/gulp-postcss/node_modules/fancy-log": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/fancy-log/-/fancy-log-2.0.0.tgz",
"integrity": "sha512-9CzxZbACXMUXW13tS0tI8XsGGmxWzO2DmYrGuBJOJ8k8q2K7hwfJA5qHjuPPe8wtsco33YR9wc+Rlr5wYFvhSA==",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"color-support": "^1.1.3"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/gulp-postcss/node_modules/plugin-error": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/plugin-error/-/plugin-error-2.0.1.tgz",
"integrity": "sha512-zMakqvIDyY40xHOvzXka0kUvf40nYIuwRE8dWhti2WtjQZ31xAgBZBhxsK7vK3QbRXS1Xms/LO7B5cuAsfB2Gg==",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"ansi-colors": "^1.0.1"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/gulp-rename": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/gulp-rename/-/gulp-rename-2.0.0.tgz",
"integrity": "sha512-97Vba4KBzbYmR5VBs9mWmK+HwIf5mj+/zioxfZhOKeXtx5ZjBk57KFlePf5nxq9QsTtFl0ejnHE3zTC9MHXqyQ==",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dev": true,
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=4"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/gulp-replace": {
"version": "1.1.4",
"resolved": "https://registry.npmjs.org/gulp-replace/-/gulp-replace-1.1.4.tgz",
"integrity": "sha512-SVSF7ikuWKhpAW4l4wapAqPPSToJoiNKsbDoUnRrSgwZHH7lH8pbPeQj1aOVYQrbZKhfSVBxVW+Py7vtulRktw==",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"@types/node": "*",
"@types/vinyl": "^2.0.4",
"istextorbinary": "^3.0.0",
"replacestream": "^4.0.3",
"yargs-parser": ">=5.0.0-security.0"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/gulp-zip": {
"version": "6.0.0",
"resolved": "https://registry.npmjs.org/gulp-zip/-/gulp-zip-6.0.0.tgz",
"integrity": "sha512-fPGvNve2dBoZxGKcviTU7mOa77eQibyhwgGLTxnF+ZCKX8RFaTZKkPbdPnmw0r4TNPRjPCkQB/0VuP+MzgkEYg==",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"get-stream": "^8.0.1",
"gulp-plugin-extras": "^0.3.0",
"vinyl": "^3.0.0",
"yazl": "^2.5.1"
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=18"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
},
"peerDependencies": {
"gulp": ">=4"
},
"peerDependenciesMeta": {
"gulp": {
"optional": true
}
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/gulplog": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "2.2.0",
"resolved": "https://registry.npmjs.org/gulplog/-/gulplog-2.2.0.tgz",
"integrity": "sha512-V2FaKiOhpR3DRXZuYdRLn/qiY0yI5XmqbTKrYbdemJ+xOh2d2MOweI/XFgMzd/9+1twdvMwllnZbWZNJ+BOm4A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"glogg": "^2.2.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/has": {
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/has/-/has-1.0.3.tgz",
"integrity": "sha512-f2dvO0VU6Oej7RkWJGrehjbzMAjFp5/VKPp5tTpWIV4JHHZK1/BxbFRtf/siA2SWTe09caDmVtYYzWEIbBS4zw==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"function-bind": "^1.1.1"
Update npm packages
2022-09-18 10:31:32 +02:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 0.4.0"
Update npm packages
2022-09-18 10:31:32 +02:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/has-bigints": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/has-bigints/-/has-bigints-1.0.2.tgz",
"integrity": "sha512-tSvCKtBr9lkF0Ex0aQiP9N+OpV4zi2r/Nee5VkRDbaqv35RLYMzbwQfFSZZH0kR+Rd6302UJZ2p/bJCEoR3VoQ==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true,
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/has-flag": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/has-flag/-/has-flag-3.0.0.tgz",
"integrity": "sha1-tdRU3CGZriJWmfNGfloH87lVuv0=",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/has-property-descriptors": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/has-property-descriptors/-/has-property-descriptors-1.0.0.tgz",
"integrity": "sha512-62DVLZGoiEBDHQyqG4w9xCuZ7eJEwNmJRWw2VY84Oedb7WFcA27fiEVe8oUQx9hAUJ4ekurquucTGwsyO1XGdQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"get-intrinsic": "^1.1.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/has-proto": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/has-proto/-/has-proto-1.0.1.tgz",
"integrity": "sha512-7qE+iP+O+bgF9clE5+UoBFzE65mlBiVj3tKCrlNQ0Ogwm0BjpT/gK4SlLYDMybDh5I3TCTKnPPa0oMG7JDYrhg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 0.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/has-symbols": {
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/has-symbols/-/has-symbols-1.0.3.tgz",
"integrity": "sha512-l3LCuF6MgDNwTDKkdYGEihYjt5pRPbEg46rtlmnSPlUbgmB8LOIrKJbYYFBSbnPaJexMKtiPO8hmeRjRz2Td+A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/has-tostringtag": {
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"version": "1.0.0",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"resolved": "https://registry.npmjs.org/has-tostringtag/-/has-tostringtag-1.0.0.tgz",
"integrity": "sha512-kFjcSNhnlGV1kyoGk7OXKSawH5JOb/LzUc5w9B02hOTO0dfFRjbHQKvg1d6cf3HbeUmtU9VbbV3qzZ2Teh97WQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"has-symbols": "^1.0.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/has-unicode": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/has-unicode/-/has-unicode-2.0.1.tgz",
"integrity": "sha1-4Ob+aijPUROIVeCG0Wkedx3iqLk=",
"dev": true
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"node_modules/hasown": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/hasown/-/hasown-2.0.0.tgz",
"integrity": "sha512-vUptKVTpIJhcczKBbgnS+RtcuYMB8+oNzPK2/Hp3hanz8JmpATdmmgLgSaadVREkDm+e2giHwY3ZRkyjSIDDFA==",
"dev": true,
"dependencies": {
"function-bind": "^1.1.2"
},
"engines": {
"node": ">= 0.4"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/highlight.js": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "11.10.0",
"resolved": "https://registry.npmjs.org/highlight.js/-/highlight.js-11.10.0.tgz",
"integrity": "sha512-SYVnVFswQER+zu1laSya563s+F8VDGt7o35d4utbamowvUNLLMovFqwCLSocpZTz3MgaSRA1IbqRWZv97dtErQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "BSD-3-Clause",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=12.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/homedir-polyfill": {
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/homedir-polyfill/-/homedir-polyfill-1.0.3.tgz",
"integrity": "sha512-eSmmWE5bZTK2Nou4g0AI3zZ9rswp7GRKoKXS1BLUkvPviOqs4YTN1djQIqrXy9k5gEtdLPy86JjRwsNM9tnDcA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"parse-passwd": "^1.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=0.10.0"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/hosted-git-info": {
"version": "2.8.9",
"resolved": "https://registry.npmjs.org/hosted-git-info/-/hosted-git-info-2.8.9.tgz",
"integrity": "sha512-mxIDAb9Lsm6DoOJ7xH+5+X4y1LU/4Hi50L9C5sIswK3JzULS4bwk1FvjdBgvYR4bzT4tuUQiC15FE2f5HbLvYw==",
"dev": true
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/html-escaper": {
"version": "2.0.2",
"resolved": "https://registry.npmjs.org/html-escaper/-/html-escaper-2.0.2.tgz",
"integrity": "sha512-H2iMtd0I4Mt5eYiapRdIDjp+XzelXQ0tFE4JS7YFwFevXXMmOp9myNrUvCg0D6ws8iqkRPBfKHgbwig1SmlLfg==",
"dev": true
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/html-tags": {
Update packages to the most recent versions
2023-04-23 13:48:22 +02:00
"version": "3.3.1",
"resolved": "https://registry.npmjs.org/html-tags/-/html-tags-3.3.1.tgz",
"integrity": "sha512-ztqyC3kLto0e9WbNp0aeP+M3kTt+nbaIveGmUxAtZa+8iFgKLUOD4YKM5j+f3QD89bra7UeumolZHKuOXnTmeQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/htmlparser2": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "9.1.0",
"resolved": "https://registry.npmjs.org/htmlparser2/-/htmlparser2-9.1.0.tgz",
"integrity": "sha512-5zfg6mHUoaer/97TxnGpxmbR7zJtPwIYFMZ/H5ucTlPZhKvtum05yiPK3Mgai3a0DyVxv7qYqoweaEd2nrYQzQ==",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dev": true,
"funding": [
"https://github.com/fb55/htmlparser2?sponsor=1",
{
"type": "github",
"url": "https://github.com/sponsors/fb55"
}
],
"dependencies": {
"domelementtype": "^2.3.0",
Update npm packages
2024-03-17 13:50:21 +01:00
"domhandler": "^5.0.3",
"domutils": "^3.1.0",
"entities": "^4.5.0"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
}
},
"node_modules/htmlparser2/node_modules/entities": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "4.5.0",
"resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz",
"integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=0.12"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"url": "https://github.com/fb55/entities?sponsor=1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"node_modules/http-proxy-agent": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/http-proxy-agent/-/http-proxy-agent-7.0.2.tgz",
"integrity": "sha512-T1gkAiYYDWYx3V5Bmyu7HcfcvL7mUrTWiM6yOfa3PIphViJ/gFPbvidQ+veqSOHci/PxBcDabeUNCzpOODJZig==",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dependencies": {
"agent-base": "^7.1.0",
"debug": "^4.3.4"
},
"engines": {
"node": ">= 14"
}
},
"node_modules/http-proxy-agent/node_modules/agent-base": {
Update dependencies to the most recent versions
2024-04-03 14:42:19 +02:00
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/agent-base/-/agent-base-7.1.1.tgz",
"integrity": "sha512-H0TSyFNDMomMNJQBn8wFV5YC/2eJ+VXECwOadZJT554xP6cODZHPX3H9QMQECxvrgiSOP1pHjy1sMWQVYJOUOA==",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dependencies": {
"debug": "^4.3.4"
},
"engines": {
"node": ">= 14"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/https-proxy-agent": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/https-proxy-agent/-/https-proxy-agent-5.0.1.tgz",
"integrity": "sha512-dFcAjpTQFgoLMzC2VwU+C/CbS7uRL0lWmxDITmqm7C+7F0Odmj6s9l6alZc6AELXhrnggM2CeWSXHGOdX2YtwA==",
Update npm packages
2023-01-15 10:34:56 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"agent-base": "6",
"debug": "4"
Update npm packages
2023-01-15 10:34:56 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 6"
Update npm packages
2023-01-15 10:34:56 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/iconv-lite": {
"version": "0.6.3",
"resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.6.3.tgz",
"integrity": "sha512-4fCk79wshMdzMp2rH06qWrJE4iolqLhCUH+OiuIgU++RB0+94NlDL81atO7GX55uUKueo0txHNtvEyI6D7WdMw==",
"dev": true,
"license": "MIT",
"dependencies": {
"safer-buffer": ">= 2.1.2 < 3.0.0"
},
"engines": {
"node": ">=0.10.0"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/ieee754": {
"version": "1.2.1",
"resolved": "https://registry.npmjs.org/ieee754/-/ieee754-1.2.1.tgz",
"integrity": "sha512-dcyqhDvX1C46lXZcVqCpK+FtMRQVdIMN6/Df5js2zouUsqG7I6sFxitIC+7KYK29KdXOLHdu9zL4sFnoVQnqaA==",
Update npm packages
2023-01-15 10:34:56 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/feross"
},
{
"type": "patreon",
"url": "https://www.patreon.com/feross"
},
{
"type": "consulting",
"url": "https://feross.org/support"
}
]
},
"node_modules/ignore": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "5.3.1",
"resolved": "https://registry.npmjs.org/ignore/-/ignore-5.3.1.tgz",
"integrity": "sha512-5Fytz/IraMjqpwfd34ke28PTVMjZjJG2MPn5t7OE4eUCUNf8BAa7b5WUS9/Qvr6mwOQS7Mk6vdsMno5he+T8Xw==",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dev": true,
"engines": {
"node": ">= 4"
Update npm packages
2023-01-15 10:34:56 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/import-fresh": {
"version": "3.3.0",
"resolved": "https://registry.npmjs.org/import-fresh/-/import-fresh-3.3.0.tgz",
"integrity": "sha512-veYYhQa+D1QBKznvhUHxb8faxlrwUnxseDAbAp457E0wLNio2bOSKnjYDhMj+YiAq61xrMGhQk9iXVk5FzgQMw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"parent-module": "^1.0.0",
"resolve-from": "^4.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=6"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/imurmurhash": {
"version": "0.1.4",
"resolved": "https://registry.npmjs.org/imurmurhash/-/imurmurhash-0.1.4.tgz",
"integrity": "sha1-khi5srkoojixPcT7a21XbyMUU+o=",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"dev": true,
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=0.8.19"
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/indent-string": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/indent-string/-/indent-string-4.0.0.tgz",
"integrity": "sha512-EdDDZu4A2OyIK7Lr/2zG+w5jmbuk1DVBnEwREQvBzspBJkCEbRa8GxU1lghYcaGJCnRWibjDXlq779X1/y5xwg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/inflight": {
"version": "1.0.6",
"resolved": "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz",
"integrity": "sha1-Sb1jMdfQLQwJvJEKEHW6gWW1bfk=",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"once": "^1.3.0",
"wrappy": "1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/inherits": {
"version": "2.0.4",
"resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz",
"integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==",
"dev": true
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/ini": {
"version": "1.3.7",
"resolved": "https://registry.npmjs.org/ini/-/ini-1.3.7.tgz",
"integrity": "sha512-iKpRpXP+CrP2jyrxvg1kMUpXDyRUFDWurxbnVT1vQPx+Wz9uCYsMIqYuSBLV+PAaZG/d7kRLKRFc9oDMsH+mFQ==",
"dev": true
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/inputformat-to-jstransformer": {
"version": "1.4.0",
"resolved": "https://registry.npmjs.org/inputformat-to-jstransformer/-/inputformat-to-jstransformer-1.4.0.tgz",
"integrity": "sha512-Ub+Wjb0mjaND4IS/GDvQ+TEyd1i9U4OdrF58mBY7QTYu8CK5K34DPV7mrvo/WQBJLj7UJWQc7QAmFb7CbQ5lLw==",
"dev": true,
"license": "MIT",
"dependencies": {
"require-one": "^1.0.3"
},
"engines": {
"node": ">=4"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/internal-slot": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "1.0.5",
"resolved": "https://registry.npmjs.org/internal-slot/-/internal-slot-1.0.5.tgz",
"integrity": "sha512-Y+R5hJrzs52QCG2laLn4udYVnxsfny9CpOhNhUvk/SSSVyF6T27FzRbF0sroPidSu3X8oEAkOn2K804mjpt6UQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2023-08-06 09:22:20 +02:00
"get-intrinsic": "^1.2.0",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"has": "^1.0.3",
"side-channel": "^1.0.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 0.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/interpret": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "3.1.1",
"resolved": "https://registry.npmjs.org/interpret/-/interpret-3.1.1.tgz",
"integrity": "sha512-6xwYfHbajpoF0xLW+iwLkhwgvLoZDfjYfoFNu8ftMoXINzwuymNLd9u/KmwtdT2GbR+/Cz66otEGEVVUHX9QLQ==",
Update `gulp-cli` to 2.3.0 and explicitly add it as a dependency
2024-01-10 14:59:32 +01:00
"dev": true,
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">=10.13.0"
Update `gulp-cli` to 2.3.0 and explicitly add it as a dependency
2024-01-10 14:59:32 +01:00
}
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"node_modules/ip-address": {
"version": "9.0.5",
"resolved": "https://registry.npmjs.org/ip-address/-/ip-address-9.0.5.tgz",
"integrity": "sha512-zHtQzGojZXTwZTHQqra+ETKd4Sn3vgi7uBmlPoXVWZqYvuKmtI0l/VZTjqGmJY9x88GGOaZ9+G9ES8hC4T4X8g==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"dependencies": {
"jsbn": "1.1.0",
"sprintf-js": "^1.1.3"
},
"engines": {
"node": ">= 12"
}
},
"node_modules/ip-address/node_modules/sprintf-js": {
"version": "1.1.3",
"resolved": "https://registry.npmjs.org/sprintf-js/-/sprintf-js-1.1.3.tgz",
"integrity": "sha512-Oo+0REFV59/rz3gfJNKQiBlwfHaSESl1pcGyABQsnnIfWOFt6JNj5gCog2U6MLZ//IGYD+nA8nI+mTShREReaA==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "BSD-3-Clause"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-absolute": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/is-absolute/-/is-absolute-1.0.0.tgz",
"integrity": "sha512-dOWoqflvcydARa360Gvv18DZ/gRuHKi2NU/wU5X1ZFzdYfH29nkiNZsF3mp4OJ3H4yo9Mx8A/uAGNzpzPN3yBA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"is-relative": "^1.0.0",
"is-windows": "^1.0.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=0.10.0"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-array-buffer": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "3.0.2",
"resolved": "https://registry.npmjs.org/is-array-buffer/-/is-array-buffer-3.0.2.tgz",
"integrity": "sha512-y+FyyR/w8vfIRq4eQcM1EYgSTnmHXPqaF+IgzgraytCFq5Xh8lllDVmAZolPJiZttZLeFSINPYMaEJ7/vWUa1w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"call-bind": "^1.0.2",
Update npm packages
2023-08-06 09:22:20 +02:00
"get-intrinsic": "^1.2.0",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"is-typed-array": "^1.1.10"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-arrayish": {
"version": "0.2.1",
"resolved": "https://registry.npmjs.org/is-arrayish/-/is-arrayish-0.2.1.tgz",
"integrity": "sha1-d8mYQFJ6qOyxqLppe4BkWnqSap0=",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-bigint": {
"version": "1.0.4",
"resolved": "https://registry.npmjs.org/is-bigint/-/is-bigint-1.0.4.tgz",
"integrity": "sha512-zB9CruMamjym81i2JZ3UMn54PKGsQzsJeo6xvN3HJJ4CAsQNB6iRutp2To77OfCNuoxspsIhzaPoO1zyCEhFOg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"has-bigints": "^1.0.1"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-boolean-object": {
"version": "1.1.2",
"resolved": "https://registry.npmjs.org/is-boolean-object/-/is-boolean-object-1.1.2.tgz",
"integrity": "sha512-gDYaKHJmnj4aWxyj6YHyXVpdQawtVLHU5cb+eztPGczf6cjuTdwve5ZIEfgXqH4e57An1D1AKf8CZ3kYrQRqYA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"call-bind": "^1.0.2",
"has-tostringtag": "^1.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 0.4"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-callable": {
"version": "1.2.7",
"resolved": "https://registry.npmjs.org/is-callable/-/is-callable-1.2.7.tgz",
"integrity": "sha512-1BC0BVFhS/p0qtw6enp8e+8OD0UrK0oFLztSjNzhcKA3WDuJxxAPXzPuPtKkjEY9UUoEWlX/8fgKeu2S8i9JTA==",
Update npm packages
2023-01-15 10:34:56 +01:00
"dev": true,
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-core-module": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"version": "2.13.1",
"resolved": "https://registry.npmjs.org/is-core-module/-/is-core-module-2.13.1.tgz",
"integrity": "sha512-hHrIjvZsftOsvKSn2TRYl63zvxsgE0K+0mYMoH6gD4omR5IWB2KynivBQczo3+wF1cCkjzvptnI9Q0sPU66ilw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dependencies": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"hasown": "^2.0.0"
Update npm packages
2022-09-18 10:31:32 +02:00
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-date-object": {
"version": "1.0.5",
"resolved": "https://registry.npmjs.org/is-date-object/-/is-date-object-1.0.5.tgz",
"integrity": "sha512-9YQaSxsAiSwcvS33MBk3wTCVnWK+HhF8VZR2jRxehM16QcVOdHqPn4VPHmRK4lSr38n9JriurInLcP90xsYNfQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"has-tostringtag": "^1.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-extendable": {
"version": "0.1.1",
"resolved": "https://registry.npmjs.org/is-extendable/-/is-extendable-0.1.1.tgz",
"integrity": "sha1-YrEQ4omkcUGOPsNqYX1HLjAd/Ik=",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
"node": ">=0.10.0"
Update npm packages
2022-10-29 10:17:36 +02:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-extglob": {
"version": "2.1.1",
"resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz",
"integrity": "sha1-qIwCU1eR8C7TfHahueqXc8gz+MI=",
Update npm packages
2022-10-29 10:17:36 +02:00
"dev": true,
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-fullwidth-code-point": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-1.0.0.tgz",
"integrity": "sha1-754xOG8DGn8NZDr4L95QxFfvAMs=",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"number-is-nan": "^1.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-negated-glob": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/is-negated-glob/-/is-negated-glob-1.0.0.tgz",
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"integrity": "sha512-czXVVn/QEmgvej1f50BZ648vUI+em0xqMq2Sn+QncCLN4zj1UAxlT+kw/6ggQTOaZPd1HqKQGEqbpQVtJucWug==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=0.10.0"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-negative-zero": {
"version": "2.0.2",
"resolved": "https://registry.npmjs.org/is-negative-zero/-/is-negative-zero-2.0.2.tgz",
"integrity": "sha512-dqJvarLawXsFbNDeJW7zAz8ItJ9cd28YufuuFzh0G8pNHjJMnY08Dv7sYX2uF5UpQOwieAeOExEYAWWfu7ZZUA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-number-object": {
"version": "1.0.7",
"resolved": "https://registry.npmjs.org/is-number-object/-/is-number-object-1.0.7.tgz",
"integrity": "sha512-k1U0IRzLMo7ZlYIfzRu23Oh6MiIFasgpb9X76eqfFZAqwH44UI4KTBvBYIZ1dSL9ZzChTB9ShHfLkR4pdW5krQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"has-tostringtag": "^1.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 0.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-path-inside": {
"version": "3.0.3",
"resolved": "https://registry.npmjs.org/is-path-inside/-/is-path-inside-3.0.3.tgz",
"integrity": "sha512-Fd4gABb+ycGAmKou8eMftCupSir5lRxqf4aD/vd0cD2qc4HL07OjCeuHMr8Ro4CoMaeCKDB0/ECBOVWjTwUvPQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-plain-object": {
"version": "2.0.4",
"resolved": "https://registry.npmjs.org/is-plain-object/-/is-plain-object-2.0.4.tgz",
"integrity": "sha512-h5PpgXkWitc38BBMYawTYMWJHFZJVnBquFE57xFpjB8pJFiF6gZ+bU+WyI/yqXiFR5mdLsgYNaPe8uao6Uv9Og==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"isobject": "^3.0.1"
},
"engines": {
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-promise": {
"version": "2.2.2",
"resolved": "https://registry.npmjs.org/is-promise/-/is-promise-2.2.2.tgz",
"integrity": "sha512-+lP4/6lKUBfQjZ2pdxThZvLUAafmZb8OAxFb8XXtiQmS35INgr85hdOGoEs124ez1FCnZJt6jau/T+alh58QFQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-regex": {
"version": "1.1.4",
"resolved": "https://registry.npmjs.org/is-regex/-/is-regex-1.1.4.tgz",
"integrity": "sha512-kvRdxDsxZjhzUX07ZnLydzS1TU/TJlTUHHY4YLL87e37oUA49DfkLqgy+VjFocowy29cKvcSiu+kIv728jTTVg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"call-bind": "^1.0.2",
"has-tostringtag": "^1.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">= 0.4"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-relative": {
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"version": "1.0.0",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"resolved": "https://registry.npmjs.org/is-relative/-/is-relative-1.0.0.tgz",
"integrity": "sha512-Kw/ReK0iqwKeu0MITLFuj0jbPAmEiOsIwyIXvvbfa6QfmN9pkD1M+8pdk7Rl/dTKbH34/XBFMbgD4iMJhLQbGA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"is-unc-path": "^1.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=0.10.0"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-shared-array-buffer": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/is-shared-array-buffer/-/is-shared-array-buffer-1.0.2.tgz",
"integrity": "sha512-sqN2UDu1/0y6uvXyStCOzyhAjCSlHceFoMKJW8W9EU9cvic/QdsZ0kEU93HEy3IUEFZIiH/3w+AH/UQbPHNdhA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"call-bind": "^1.0.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-string": {
"version": "1.0.7",
"resolved": "https://registry.npmjs.org/is-string/-/is-string-1.0.7.tgz",
"integrity": "sha512-tE2UXzivje6ofPW7l23cjDOMa09gb7xlAqG6jG5ej6uPV32TlWP3NKPigtaGeHNu9fohccRYvIiZMfOOnOYUtg==",
Update npm packages
2023-01-15 10:34:56 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"has-tostringtag": "^1.0.0"
},
"engines": {
"node": ">= 0.4"
Update npm packages
2023-01-15 10:34:56 +01:00
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-symbol": {
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"version": "1.0.4",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"resolved": "https://registry.npmjs.org/is-symbol/-/is-symbol-1.0.4.tgz",
"integrity": "sha512-C/CPBqKWnvdcxqIARxyOh4v1UUEOCHpgDa0WYgpKDFMszcrPcffg5uhwSgPCLD2WWxmq6isisz87tzT01tuGhg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"has-symbols": "^1.0.2"
},
"engines": {
"node": ">= 0.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-typed-array": {
"version": "1.1.10",
"resolved": "https://registry.npmjs.org/is-typed-array/-/is-typed-array-1.1.10.tgz",
"integrity": "sha512-PJqgEHiWZvMpaFZ3uTc8kHPM4+4ADTlDniuQL7cU/UDA0Ql7F70yGfHph3cLNe+c9toaigv+DFzTJKhc2CtO6A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"available-typed-arrays": "^1.0.5",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"call-bind": "^1.0.2",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"for-each": "^0.3.3",
"gopd": "^1.0.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"has-tostringtag": "^1.0.0"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-unc-path": {
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"version": "1.0.0",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"resolved": "https://registry.npmjs.org/is-unc-path/-/is-unc-path-1.0.0.tgz",
"integrity": "sha512-mrGpVd0fs7WWLfVsStvgF6iEJnbjDFZh9/emhRDcGWTduTfNHd9CHeUwH3gYIjdbwo4On6hunkztwOaAw0yllQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"unc-path-regex": "^0.1.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=0.10.0"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/is-utf8": {
"version": "0.2.1",
"resolved": "https://registry.npmjs.org/is-utf8/-/is-utf8-0.2.1.tgz",
"integrity": "sha512-rMYPYvCzsXywIsldgLaSoPlw5PfoB/ssr7hY4pLfcodrA5M/eArza1a9VmTiNIBNMjOGr1Ow9mTyU2o69U6U9Q==",
"dev": true,
"license": "MIT"
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-valid-glob": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/is-valid-glob/-/is-valid-glob-1.0.0.tgz",
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"integrity": "sha512-AhiROmoEFDSsjx8hW+5sGwgKVIORcXnrlAx/R0ZSeaPw70Vw0CqkGBBhHGL58Uox2eXnU1AnvXJl1XlyedO5bA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-weakref": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/is-weakref/-/is-weakref-1.0.2.tgz",
"integrity": "sha512-qctsuLZmIQ0+vSSMfoVvyFe2+GSEvnmZ2ezTup1SBse9+twCCeial6EEi3Nc2KFcf6+qz2FBPnjXsk8xhKSaPQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"call-bind": "^1.0.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/is-windows": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/is-windows/-/is-windows-1.0.2.tgz",
"integrity": "sha512-eXK1UInq2bPmjyX6e3VHIzMLobc4J94i4AWn+Hpq3OU5KkrRC96OAcR3PRJ/pGu6m8TRnBHP9dkXQVsT/COVIA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node": ">=0.10.0"
}
},
"node_modules/isarray": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/isarray/-/isarray-1.0.0.tgz",
"integrity": "sha1-u5NdSFgsuhaMBoNJV6VKPgcSTxE=",
"dev": true
},
"node_modules/isexe": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/isexe/-/isexe-2.0.0.tgz",
"integrity": "sha1-6PvzdNxVb/iUehDcsFctYz8s+hA=",
"dev": true
},
"node_modules/isobject": {
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/isobject/-/isobject-3.0.1.tgz",
"integrity": "sha1-TkMekrEalzFjaqH5yNHMvP2reN8=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/istanbul-lib-coverage": {
"version": "3.2.2",
"resolved": "https://registry.npmjs.org/istanbul-lib-coverage/-/istanbul-lib-coverage-3.2.2.tgz",
"integrity": "sha512-O8dpsF+r0WV/8MNRKfnmrtCWhuKjxrq2w+jpzBL5UZKTi2LeVWnWOmWRxFlesJONmc+wLAGvKQZEOanko0LFTg==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/istanbul-lib-hook": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/istanbul-lib-hook/-/istanbul-lib-hook-3.0.0.tgz",
"integrity": "sha512-Pt/uge1Q9s+5VAZ+pCo16TYMWPBIl+oaNIjgLQxcX0itS6ueeaA+pEfThZpH8WxhFgCiEb8sAJY6MdUKgiIWaQ==",
"dev": true,
"dependencies": {
"append-transform": "^2.0.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/istanbul-lib-instrument": {
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/istanbul-lib-instrument/-/istanbul-lib-instrument-6.0.1.tgz",
"integrity": "sha512-EAMEJBsYuyyztxMxW3g7ugGPkrZsV57v0Hmv3mm1uQsmB+QnZuepg731CRaIgeUVSdmsTngOkSnauNF8p7FIhA==",
"dev": true,
"dependencies": {
"@babel/core": "^7.12.3",
"@babel/parser": "^7.14.7",
"@istanbuljs/schema": "^0.1.2",
"istanbul-lib-coverage": "^3.2.0",
"semver": "^7.5.4"
},
"engines": {
"node": ">=10"
}
},
"node_modules/istanbul-lib-instrument/node_modules/semver": {
"version": "7.5.4",
"resolved": "https://registry.npmjs.org/semver/-/semver-7.5.4.tgz",
"integrity": "sha512-1bCSESV6Pv+i21Hvpxp3Dx+pSD8lIPt8uVjRrxAUt/nbswYc+tK6Y2btiULjd4+fnq15PX+nqQDC7Oft7WkwcA==",
"dev": true,
"dependencies": {
"lru-cache": "^6.0.0"
},
"bin": {
"semver": "bin/semver.js"
},
"engines": {
"node": ">=10"
}
},
"node_modules/istanbul-lib-report": {
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/istanbul-lib-report/-/istanbul-lib-report-3.0.1.tgz",
"integrity": "sha512-GCfE1mtsHGOELCU8e/Z7YWzpmybrx/+dSTfLrvY8qRmaY6zXTKWn6WQIjaAFw069icm6GVMNkgu0NzI4iPZUNw==",
"dev": true,
"dependencies": {
"istanbul-lib-coverage": "^3.0.0",
"make-dir": "^4.0.0",
"supports-color": "^7.1.0"
},
"engines": {
"node": ">=10"
}
},
"node_modules/istanbul-lib-report/node_modules/has-flag": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz",
"integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/istanbul-lib-report/node_modules/make-dir": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/make-dir/-/make-dir-4.0.0.tgz",
"integrity": "sha512-hXdUTZYIVOt1Ex//jAQi+wTZZpUpwBj/0QsOzqegb3rGMMeJiSEu5xLHnYfBrRV4RH2+OCSOO95Is/7x1WJ4bw==",
"dev": true,
"dependencies": {
"semver": "^7.5.3"
},
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/istanbul-lib-report/node_modules/semver": {
"version": "7.5.4",
"resolved": "https://registry.npmjs.org/semver/-/semver-7.5.4.tgz",
"integrity": "sha512-1bCSESV6Pv+i21Hvpxp3Dx+pSD8lIPt8uVjRrxAUt/nbswYc+tK6Y2btiULjd4+fnq15PX+nqQDC7Oft7WkwcA==",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"dev": true,
"dependencies": {
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"lru-cache": "^6.0.0"
},
"bin": {
"semver": "bin/semver.js"
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
},
"engines": {
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node": ">=10"
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/istanbul-lib-report/node_modules/supports-color": {
"version": "7.2.0",
"resolved": "https://registry.npmjs.org/supports-color/-/supports-color-7.2.0.tgz",
"integrity": "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"dev": true,
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"dependencies": {
"has-flag": "^4.0.0"
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
},
"engines": {
"node": ">=8"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/istanbul-reports": {
"version": "3.1.6",
"resolved": "https://registry.npmjs.org/istanbul-reports/-/istanbul-reports-3.1.6.tgz",
"integrity": "sha512-TLgnMkKg3iTDsQ9PbPTdpfAK2DzjF9mqUG7RMgcQl8oFjad8ob4laGxv5XV5U9MAfx8D6tSJiUyuAwzLicaxlg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"dependencies": {
"html-escaper": "^2.0.0",
"istanbul-lib-report": "^3.0.0"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/istextorbinary": {
"version": "3.3.0",
"resolved": "https://registry.npmjs.org/istextorbinary/-/istextorbinary-3.3.0.tgz",
"integrity": "sha512-Tvq1W6NAcZeJ8op+Hq7tdZ434rqnMx4CCZ7H0ff83uEloDvVbqAwaMTZcafKGJT0VHkYzuXUiCY4hlXQg6WfoQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"binaryextensions": "^2.2.0",
"textextensions": "^3.2.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"url": "https://bevry.me/fund"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node_modules/jackspeak": {
Update npm packages
2024-01-06 10:09:12 +01:00
"version": "2.3.6",
"resolved": "https://registry.npmjs.org/jackspeak/-/jackspeak-2.3.6.tgz",
"integrity": "sha512-N3yCS/NegsOBokc8GAdM8UcmfsKiSS8cipheD/nivzr700H+nsMOxJjQnvwOcRYVuFkdH0wGUvW2WbXGmrZGbQ==",
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"dev": true,
"dependencies": {
"@isaacs/cliui": "^8.0.2"
},
"engines": {
"node": ">=14"
},
"funding": {
"url": "https://github.com/sponsors/isaacs"
},
"optionalDependencies": {
"@pkgjs/parseargs": "^0.11.0"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jasmine": {
Update npm packages
2023-07-23 09:49:53 +02:00
"version": "5.1.0",
"resolved": "https://registry.npmjs.org/jasmine/-/jasmine-5.1.0.tgz",
"integrity": "sha512-prmJlC1dbLhti4nE4XAPDWmfJesYO15sjGXVp7Cs7Ym5I9Xtwa/hUHxxJXjnpfLO72+ySttA0Ztf8g/RiVnUKw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"glob": "^10.2.2",
Update npm packages
2023-07-23 09:49:53 +02:00
"jasmine-core": "~5.1.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"bin": {
"jasmine": "bin/jasmine.js"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jasmine-core": {
Update npm packages
2023-07-23 09:49:53 +02:00
"version": "5.1.0",
"resolved": "https://registry.npmjs.org/jasmine-core/-/jasmine-core-5.1.0.tgz",
"integrity": "sha512-bFMMwpKuTZXCuGd51yClFobw5SOtad1kmdWnYO8dNwYV8i01Xj0C2+nyQpSKl1EKxiPfyd1ZgBl/rsusL3aS6w==",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dev": true
},
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node_modules/jasmine/node_modules/brace-expansion": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz",
"integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==",
"dev": true,
"dependencies": {
"balanced-match": "^1.0.0"
}
},
Revert "Update `rimraf` to version 4" This reverts commit 32357e3d172a552e0408b3e1ed743e87fe7d5a21.
2023-03-06 19:47:18 +01:00
"node_modules/jasmine/node_modules/glob": {
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"version": "10.2.3",
"resolved": "https://registry.npmjs.org/glob/-/glob-10.2.3.tgz",
"integrity": "sha512-Kb4rfmBVE3eQTAimgmeqc2LwSnN0wIOkkUL6HmxEFxNJ4fHghYHVbFba/HcGcRjE6s9KoMNK3rSOwkL4PioZjg==",
Revert "Update `rimraf` to version 4" This reverts commit 32357e3d172a552e0408b3e1ed743e87fe7d5a21.
2023-03-06 19:47:18 +01:00
"dev": true,
"dependencies": {
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"foreground-child": "^3.1.0",
"jackspeak": "^2.0.3",
"minimatch": "^9.0.0",
"minipass": "^5.0.0",
"path-scurry": "^1.7.0"
},
"bin": {
"glob": "dist/cjs/src/bin.js"
Revert "Update `rimraf` to version 4" This reverts commit 32357e3d172a552e0408b3e1ed743e87fe7d5a21.
2023-03-06 19:47:18 +01:00
},
"engines": {
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node": ">=16 || 14 >=14.17"
Revert "Update `rimraf` to version 4" This reverts commit 32357e3d172a552e0408b3e1ed743e87fe7d5a21.
2023-03-06 19:47:18 +01:00
},
"funding": {
"url": "https://github.com/sponsors/isaacs"
}
},
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node_modules/jasmine/node_modules/minimatch": {
"version": "9.0.0",
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.0.tgz",
"integrity": "sha512-0jJj8AvgKqWN05mrwuqi8QYKx1WmYSUoKSxu5Qhs9prezTz10sxAHGNZe9J9cqIJzta8DWsleh2KaVaLl6Ru2w==",
"dev": true,
"dependencies": {
"brace-expansion": "^2.0.1"
},
"engines": {
"node": ">=16 || 14 >=14.17"
},
"funding": {
"url": "https://github.com/sponsors/isaacs"
}
},
"node_modules/jasmine/node_modules/minipass": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/minipass/-/minipass-5.0.0.tgz",
"integrity": "sha512-3FnjYuehv9k6ovOEbyOswadCDPX1piCfhV8ncmYtHOjuPwylVWsghTLo7rabjC3Rx5xD4HDx8Wm1xnMF7S5qFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jest-worker": {
Update npm packages
2023-04-15 22:08:58 +02:00
"version": "27.5.1",
"resolved": "https://registry.npmjs.org/jest-worker/-/jest-worker-27.5.1.tgz",
"integrity": "sha512-7vuh85V5cdDofPyxn58nrPjBktZo0u9x1g8WtjQol+jZDaE+fhN+cIvTj11GndBnMnyfrUOG1sZQxCdjKh+DKg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dependencies": {
"@types/node": "*",
"merge-stream": "^2.0.0",
"supports-color": "^8.0.0"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jest-worker/node_modules/has-flag": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz",
"integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jest-worker/node_modules/supports-color": {
"version": "8.1.1",
"resolved": "https://registry.npmjs.org/supports-color/-/supports-color-8.1.1.tgz",
"integrity": "sha512-MpUEN2OodtUzxvKQl72cUF7RQ5EiHsGvSsVG0ia9c5RbWGL2CI4C7EpPS8UTBIplnlzZiNuV56w+FuNxy3ty2Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dependencies": {
"has-flag": "^4.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=10"
},
"funding": {
"url": "https://github.com/chalk/supports-color?sponsor=1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/js-tokens": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/js-tokens/-/js-tokens-4.0.0.tgz",
"integrity": "sha512-RdJUflcE3cUzKiMqQgsCu06FPu9UdIJO0beYbPhHN4k6apgJtifcoCtT9bcxOpYBtpD2kCM6Sbzg4CausW/PKQ==",
"dev": true
},
"node_modules/js-yaml": {
"version": "3.13.1",
"resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-3.13.1.tgz",
"integrity": "sha512-YfbcO7jXDdyj0DGxYVSlSeQNHbD7XPWvrVWeVUujrQEoZzWJIRrCPoyk6kL6IAjAG2IolMK4T0hNUe0HOUs5Jw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dependencies": {
"argparse": "^1.0.7",
"esprima": "^4.0.0"
},
"bin": {
"js-yaml": "bin/js-yaml.js"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/js2xmlparser": {
"version": "4.0.2",
"resolved": "https://registry.npmjs.org/js2xmlparser/-/js2xmlparser-4.0.2.tgz",
"integrity": "sha512-6n4D8gLlLf1n5mNLQPRfViYzu9RATblzPEtm1SthMX1Pjao0r9YI9nw7ZIfRxQMERS87mcswrg+r/OYrPRX6jA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"xmlcreate": "^2.0.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"node_modules/jsbn": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/jsbn/-/jsbn-1.1.0.tgz",
"integrity": "sha512-4bYVV3aAMtDTTu4+xsDYa6sy9GyJ69/amsu9sYF2zqjiEoZA5xJi3BrfX3uY+/IekIu7MwdObdbDWpoZdBv3/A==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "MIT"
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jsdoc": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/jsdoc/-/jsdoc-4.0.3.tgz",
"integrity": "sha512-Nu7Sf35kXJ1MWDZIMAuATRQTg1iIPdzh7tqJ6jjvaU/GfDf+qi5UV8zJR3Mo+/pYFvm8mzay4+6O5EWigaQBQw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2023-03-12 10:27:52 +01:00
"@babel/parser": "^7.20.15",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"@jsdoc/salty": "^0.2.1",
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"@types/markdown-it": "^14.1.1",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"bluebird": "^3.7.2",
"catharsis": "^0.9.0",
"escape-string-regexp": "^2.0.0",
"js2xmlparser": "^4.0.2",
"klaw": "^3.0.0",
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"markdown-it": "^14.1.0",
"markdown-it-anchor": "^8.6.7",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"marked": "^4.0.10",
"mkdirp": "^1.0.4",
"requizzle": "^0.2.3",
"strip-json-comments": "^3.1.0",
"underscore": "~1.13.2"
},
"bin": {
"jsdoc": "jsdoc.js"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=12.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jsdoc/node_modules/argparse": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
"integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
"dev": true
},
"node_modules/jsdoc/node_modules/entities": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"version": "4.5.0",
"resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz",
"integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"engines": {
"node": ">=0.12"
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"funding": {
"url": "https://github.com/fb55/entities?sponsor=1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jsdoc/node_modules/escape-string-regexp": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-2.0.0.tgz",
"integrity": "sha512-UpzcLCXolUWcNu5HtVMHYdXJjArjsF9C0aNnquZYY4uW/Vu0miy5YoWvbV345HauVvcAUnpRuhMMcqTcGOY2+w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jsdoc/node_modules/linkify-it": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-5.0.0.tgz",
"integrity": "sha512-5aHCbzQRADcdP+ATqnDuhhJ/MRIqDkZX5pyjFHRRysS8vZ5AbqGEoFIb6pYHPZ+L/OC2Lc+xT8uHVVR5CAK/wQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"uc.micro": "^2.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jsdoc/node_modules/markdown-it": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"version": "14.1.0",
"resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-14.1.0.tgz",
"integrity": "sha512-a54IwgWPaeBCAAsv13YgmALOF1elABB08FxO9i+r4VFk5Vl4pKokRPeX8u5TCgSsPi6ec1otfLjdOpVcgbpshg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"argparse": "^2.0.1",
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"entities": "^4.4.0",
"linkify-it": "^5.0.0",
"mdurl": "^2.0.0",
"punycode.js": "^2.3.1",
"uc.micro": "^2.1.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"bin": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"markdown-it": "bin/markdown-it.mjs"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"node_modules/jsdoc/node_modules/mdurl": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/mdurl/-/mdurl-2.0.0.tgz",
"integrity": "sha512-Lf+9+2r+Tdp5wXDXC4PcIBjTDtq4UKjCPMQhKIuzpJNW0b96kVqSwW0bT7FhRSfmAiFYgP+SCRvdrDozfh0U5w==",
"dev": true
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jsdoc/node_modules/mkdirp": {
"version": "1.0.4",
"resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-1.0.4.tgz",
"integrity": "sha512-vVqVZQyf3WLx2Shd0qJ9xuvqgAyKPLAiqITEtqW0oIUjzo3PePDd6fW9iFz30ef7Ysp/oiWqbhszeGWW2T6Gzw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"bin": {
"mkdirp": "bin/cmd.js"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=10"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"node_modules/jsdoc/node_modules/uc.micro": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-2.1.0.tgz",
"integrity": "sha512-ARDJmphmdvUk6Glw7y9DQ2bFkKBHwQHLi2lsaH6PPmz/Ka9sFOBsBluozhDltWmnv9u/cF6Rt87znRTPV+yp/A==",
"dev": true
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jsesc": {
"version": "2.5.2",
"resolved": "https://registry.npmjs.org/jsesc/-/jsesc-2.5.2.tgz",
"integrity": "sha512-OYu7XEzjkCQ3C5Ps3QIZsQfNpqoJyZZA99wd9aWd05NCtC5pWOkShK2mkL6HXQR6/Cy2lbNdPlZBpuQHXE63gA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"bin": {
"jsesc": "bin/jsesc"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"node_modules/json-buffer": {
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/json-buffer/-/json-buffer-3.0.1.tgz",
"integrity": "sha512-4bV5BfR2mqfQTJm+V5tPPdf+ZpuhiIvTuAB5g8kcrXOZpTT/QwwVRWBywX1ozr6lEuPdbHxwaJlm9G6mI2sfSQ==",
"dev": true
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/json-parse-even-better-errors": {
"version": "2.3.1",
"resolved": "https://registry.npmjs.org/json-parse-even-better-errors/-/json-parse-even-better-errors-2.3.1.tgz",
"integrity": "sha512-xyFwyhro/JEof6Ghe2iz2NcXoj2sloNsWr/XsERDK/oiPCfaNhl5ONfp+jQdAZRQQ0IJWNzH9zIZF7li91kh2w==",
"dev": true
},
"node_modules/json-schema-traverse": {
"version": "0.4.1",
"resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-0.4.1.tgz",
"integrity": "sha512-xbbCH5dCYU5T8LcEhhuh7HJ88HXuW3qsI3Y0zOZFKfZEHcpWiHU/Jxzk629Brsab/mMiHQti9wMP+845RPe3Vg==",
"dev": true
},
"node_modules/json-stable-stringify-without-jsonify": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/json-stable-stringify-without-jsonify/-/json-stable-stringify-without-jsonify-1.0.1.tgz",
"integrity": "sha1-nbe1lJatPzz+8wp1FC0tkwrXJlE=",
"dev": true
},
"node_modules/json5": {
"version": "2.2.3",
"resolved": "https://registry.npmjs.org/json5/-/json5-2.2.3.tgz",
"integrity": "sha512-XmOWe7eyHYH14cLdVPoyg+GOH3rYX++KpzrylJwSW98t3Nk+U8XOl8FWKOgwtzdb8lXGf6zYwDUzeHMWfxasyg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"bin": {
"json5": "lib/cli.js"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=6"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jsonc-parser": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/jsonc-parser/-/jsonc-parser-3.0.0.tgz",
"integrity": "sha512-fQzRfAbIBnR0IQvftw9FJveWiHp72Fg20giDrHz6TdfB12UH/uue0D3hm57UB5KgAVuniLMCaS8P1IMj9NR7cA==",
"dev": true
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/jsonfile": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"version": "6.1.0",
"resolved": "https://registry.npmjs.org/jsonfile/-/jsonfile-6.1.0.tgz",
"integrity": "sha512-5dgndWOriYSm5cnYaJNhalLNDKOqFwyDB/rr1E9ZsGciGvKPs8R2xYGCacuf3z6K1YKDz182fd+fY3cn3pMqXQ==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"dependencies": {
"universalify": "^2.0.0"
},
Update npm packages
2023-07-23 09:49:53 +02:00
"optionalDependencies": {
"graceful-fs": "^4.1.6"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jstransformer": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/jstransformer/-/jstransformer-1.0.0.tgz",
"integrity": "sha1-7Yvwkh4vPx7U1cGkT2hwntJHIsM=",
Update npm packages
2022-10-29 10:17:36 +02:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dependencies": {
"is-promise": "^2.0.0",
"promise": "^7.0.1"
Update npm packages
2022-10-29 10:17:36 +02:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/jstransformer-nunjucks": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/jstransformer-nunjucks/-/jstransformer-nunjucks-1.2.0.tgz",
"integrity": "sha512-3v8+d486W538nJCMt6+MENHiqp18YIaUGKWAEt1Vu2rjo64ZBMLBUfOouKLGfMgamgjbQcRMpjMnrfu+bKTjJw==",
"dev": true,
"license": "MIT",
"dependencies": {
"nunjucks": "^3.2.4"
},
"engines": {
"node": ">=8.0.0"
}
},
"node_modules/jstransformer-nunjucks/node_modules/anymatch": {
"version": "3.1.3",
"resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.3.tgz",
"integrity": "sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==",
"dev": true,
"license": "ISC",
"optional": true,
"peer": true,
"dependencies": {
"normalize-path": "^3.0.0",
"picomatch": "^2.0.4"
},
"engines": {
"node": ">= 8"
}
},
"node_modules/jstransformer-nunjucks/node_modules/binary-extensions": {
"version": "2.3.0",
"resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.3.0.tgz",
"integrity": "sha512-Ceh+7ox5qe7LJuLHoY0feh3pHuUDHAcRUeyL2VYghZwfpkNIy/+8Ocg0a3UuSoYzavmylwuLWQOf3hl0jjMMIw==",
"dev": true,
"license": "MIT",
"optional": true,
"peer": true,
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/jstransformer-nunjucks/node_modules/braces": {
"version": "3.0.3",
"resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
"integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
"dev": true,
"license": "MIT",
"optional": true,
"peer": true,
"dependencies": {
"fill-range": "^7.1.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/jstransformer-nunjucks/node_modules/chokidar": {
"version": "3.6.0",
"resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.6.0.tgz",
"integrity": "sha512-7VT13fmjotKpGipCW9JEQAusEPE+Ei8nl6/g4FBAmIm0GOOLMua9NDDo/DWp0ZAxCr3cPq5ZpBqmPAQgDda2Pw==",
"dev": true,
"license": "MIT",
"optional": true,
"peer": true,
"dependencies": {
"anymatch": "~3.1.2",
"braces": "~3.0.2",
"glob-parent": "~5.1.2",
"is-binary-path": "~2.1.0",
"is-glob": "~4.0.1",
"normalize-path": "~3.0.0",
"readdirp": "~3.6.0"
},
"engines": {
"node": ">= 8.10.0"
},
"funding": {
"url": "https://paulmillr.com/funding/"
},
"optionalDependencies": {
"fsevents": "~2.3.2"
}
},
"node_modules/jstransformer-nunjucks/node_modules/commander": {
"version": "5.1.0",
"resolved": "https://registry.npmjs.org/commander/-/commander-5.1.0.tgz",
"integrity": "sha512-P0CysNDQ7rtVw4QIQtm+MRxV66vKFSvlsQvGYXZWR3qFU0jlMKHZZZgw8e+8DSah4UDKMqnknRDQz+xuQXQ/Zg==",
"dev": true,
"license": "MIT",
"engines": {
"node": ">= 6"
}
},
"node_modules/jstransformer-nunjucks/node_modules/fill-range": {
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
"integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
"dev": true,
"license": "MIT",
"optional": true,
"peer": true,
"dependencies": {
"to-regex-range": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/jstransformer-nunjucks/node_modules/glob-parent": {
"version": "5.1.2",
"resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz",
"integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==",
"dev": true,
"license": "ISC",
"optional": true,
"peer": true,
"dependencies": {
"is-glob": "^4.0.1"
},
"engines": {
"node": ">= 6"
}
},
"node_modules/jstransformer-nunjucks/node_modules/is-binary-path": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz",
"integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==",
"dev": true,
"license": "MIT",
"optional": true,
"peer": true,
"dependencies": {
"binary-extensions": "^2.0.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/jstransformer-nunjucks/node_modules/is-glob": {
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz",
"integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==",
"dev": true,
"license": "MIT",
"optional": true,
"peer": true,
"dependencies": {
"is-extglob": "^2.1.1"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/jstransformer-nunjucks/node_modules/is-number": {
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
"integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==",
"dev": true,
"license": "MIT",
"optional": true,
"peer": true,
"engines": {
"node": ">=0.12.0"
}
},
"node_modules/jstransformer-nunjucks/node_modules/normalize-path": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"version": "3.0.0",
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz",
"integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==",
"dev": true,
"license": "MIT",
"optional": true,
"peer": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/jstransformer-nunjucks/node_modules/nunjucks": {
"version": "3.2.4",
"resolved": "https://registry.npmjs.org/nunjucks/-/nunjucks-3.2.4.tgz",
"integrity": "sha512-26XRV6BhkgK0VOxfbU5cQI+ICFUtMLixv1noZn1tGU38kQH5A5nmmbk/O45xdyBhD1esk47nKrY0mvQpZIhRjQ==",
"dev": true,
"license": "BSD-2-Clause",
"dependencies": {
"a-sync-waterfall": "^1.0.0",
"asap": "^2.0.3",
"commander": "^5.1.0"
},
"bin": {
"nunjucks-precompile": "bin/precompile"
},
"engines": {
"node": ">= 6.9.0"
},
"peerDependencies": {
"chokidar": "^3.3.0"
},
"peerDependenciesMeta": {
"chokidar": {
"optional": true
}
}
},
"node_modules/jstransformer-nunjucks/node_modules/readdirp": {
"version": "3.6.0",
"resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.6.0.tgz",
"integrity": "sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==",
"dev": true,
"license": "MIT",
"optional": true,
"peer": true,
"dependencies": {
"picomatch": "^2.2.1"
},
"engines": {
"node": ">=8.10.0"
}
},
"node_modules/jstransformer-nunjucks/node_modules/to-regex-range": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
"integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
"optional": true,
"peer": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"is-number": "^7.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=8.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/jsx-ast-utils": {
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"version": "3.3.5",
"resolved": "https://registry.npmjs.org/jsx-ast-utils/-/jsx-ast-utils-3.3.5.tgz",
"integrity": "sha512-ZZow9HBI5O6EPgSJLUb8n2NKgmVWTwCvHGwFuJlMjvLFqlGG6pjirPhtdsseaLZjSibD8eegzmYpUZwoIlj2cQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"peer": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"array-includes": "^3.1.6",
"array.prototype.flat": "^1.3.1",
"object.assign": "^4.1.4",
"object.values": "^1.1.6"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=4.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"node_modules/keyv": {
"version": "4.5.4",
"resolved": "https://registry.npmjs.org/keyv/-/keyv-4.5.4.tgz",
"integrity": "sha512-oxVHkHR/EJf2CNXnWxRLW6mg7JyCCUcG0DtEGmL2ctUo1PNTin1PUil+r/+4r5MpVgC/fn1kjsx7mjSujKqIpw==",
"dev": true,
"dependencies": {
"json-buffer": "3.0.1"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/kind-of": {
"version": "6.0.3",
"resolved": "https://registry.npmjs.org/kind-of/-/kind-of-6.0.3.tgz",
"integrity": "sha512-dcS1ul+9tmeD95T+x28/ehLgd9mENa3LsvDTtzm3vyBEO7RPptvAD+t44WVXaUjTBRcrpFeFlC8WCruUR456hw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/klaw": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/klaw/-/klaw-3.0.0.tgz",
"integrity": "sha512-0Fo5oir+O9jnXu5EefYbVK+mHMBeEVEy2cmctR1O1NECcCkPRreJKrS6Qt/j3KC2C148Dfo9i3pCmCMsdqGr0g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update npm packages
2022-09-18 10:31:32 +02:00
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"graceful-fs": "^4.1.9"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/known-css-properties": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "0.34.0",
"resolved": "https://registry.npmjs.org/known-css-properties/-/known-css-properties-0.34.0.tgz",
"integrity": "sha512-tBECoUqNFbyAY4RrbqsBQqDFpGXAEbdD5QKr8kACx3+rnArmuuR22nKQWKazvp07N9yjTyDZaw/20UIH8tL9DQ==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "MIT"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
"node_modules/last-run": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/last-run/-/last-run-2.0.0.tgz",
"integrity": "sha512-j+y6WhTLN4Itnf9j5ZQos1BGPCS8DAwmgMroR3OzfxAsBxam0hMw7J8M3KqZl0pLQJ1jNnwIexg5DYpC/ctwEQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/lead": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/lead/-/lead-4.0.0.tgz",
"integrity": "sha512-DpMa59o5uGUWWjruMp71e6knmwKU3jRBBn1kjuLWN9EeIOxNeSAwvHf03WIl8g/ZMR2oSQC9ej3yeLBwdDc/pg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/liftoff": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/liftoff/-/liftoff-5.0.0.tgz",
"integrity": "sha512-a5BQjbCHnB+cy+gsro8lXJ4kZluzOijzJ1UVVfyJYZC+IP2pLv1h4+aysQeKuTmyO8NAqfyQAk4HWaP/HjcKTg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"extend": "^3.0.2",
"findup-sync": "^5.0.0",
"fined": "^2.0.0",
"flagged-respawn": "^2.0.0",
"is-plain-object": "^5.0.0",
"rechoir": "^0.8.0",
"resolve": "^1.20.0"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">=10.13.0"
}
},
"node_modules/liftoff/node_modules/is-plain-object": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/is-plain-object/-/is-plain-object-5.0.0.tgz",
"integrity": "sha512-VRSzKkbMm5jMDoKLbltAkFQ5Qr7VDiTFGXxYFXXowVj387GeGNOCsOH6Msy00SGZ3Fp84b1Naa1psqgcCIEP5Q==",
"dev": true,
"engines": {
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/lilconfig": {
Update npm packages
2024-01-20 09:40:33 +01:00
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/lilconfig/-/lilconfig-3.0.0.tgz",
"integrity": "sha512-K2U4W2Ff5ibV7j7ydLr+zLAkIg5JJ4lPn1Ltsdt+Tz/IjQ8buJ55pZAxoP34lqIiwtF9iAvtLv3JGv7CAyAg+g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Update npm packages
2024-01-20 09:40:33 +01:00
"node": ">=14"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/lines-and-columns": {
"version": "1.1.6",
"resolved": "https://registry.npmjs.org/lines-and-columns/-/lines-and-columns-1.1.6.tgz",
"integrity": "sha1-HADHQ7QzzQpOgHWPe2SldEDZ/wA=",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/linkify-it": {
"version": "4.0.1",
"resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-4.0.1.tgz",
"integrity": "sha512-C7bfi1UZmoj8+PQx22XyeXCuBlokoyWQL5pWSP+EI6nzRylyThouddufc2c1NDIcP9k5agmN9fLpA7VNJfIiqw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"peer": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"uc.micro": "^1.0.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/loader-runner": {
"version": "4.2.0",
"resolved": "https://registry.npmjs.org/loader-runner/-/loader-runner-4.2.0.tgz",
"integrity": "sha512-92+huvxMvYlMzMt0iIOukcwYBFpkYJdpl2xsZ7LrlayO7E8SOv+JJUEK17B/dJIHAOLMfh2dZZ/Y18WgmGtYNw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
"node": ">=6.11.5"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node_modules/locate-path": {
"version": "7.2.0",
"resolved": "https://registry.npmjs.org/locate-path/-/locate-path-7.2.0.tgz",
"integrity": "sha512-gvVijfZvn7R+2qyPX8mAuKcFGDf6Nc61GdvGafQsHL0sBIxfKzA+usWn4GFC/bk+QdwPUD4kWFJLhElipq+0VA==",
"dev": true,
"dependencies": {
"p-locate": "^6.0.0"
},
"engines": {
"node": "^12.20.0 || ^14.13.1 || >=16.0.0"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/lodash": {
"version": "4.17.21",
"resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
"integrity": "sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==",
"dev": true
},
"node_modules/lodash.clone": {
Update npm packages
2022-11-13 21:28:21 +01:00
"version": "4.5.0",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"resolved": "https://registry.npmjs.org/lodash.clone/-/lodash.clone-4.5.0.tgz",
"integrity": "sha1-GVhwRQ9aExkkeN9Lw9I9LeoZB7Y=",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/lodash.clonedeepwith": {
"version": "4.5.0",
"resolved": "https://registry.npmjs.org/lodash.clonedeepwith/-/lodash.clonedeepwith-4.5.0.tgz",
"integrity": "sha512-QRBRSxhbtsX1nc0baxSkkK5WlVTTm/s48DSukcGcWZwIyI8Zz+lB+kFiELJXtzfH4Aj6kMWQ1VWW4U5uUDgZMA==",
"dev": true,
"license": "MIT"
},
"node_modules/lodash.debounce": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"version": "4.0.8",
"resolved": "https://registry.npmjs.org/lodash.debounce/-/lodash.debounce-4.0.8.tgz",
"integrity": "sha512-FT1yDzDYEoYWhnSGnpE/4Kj1fLZkDFyqRb7fNt6FdYOSxlUWAtp42Eh6Wb0rGIv/m9Bgo7x4GhQbm5Ys4SG5ow==",
"dev": true
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/lodash.isplainobject": {
"version": "4.0.6",
"resolved": "https://registry.npmjs.org/lodash.isplainobject/-/lodash.isplainobject-4.0.6.tgz",
"integrity": "sha512-oSXzaWypCMHkPC3NvBEaPHf0KsA5mvPrOPgQWDsbg8n7orZ290M0BmC/jgRZ4vcJ6DTAhjrsSYgdsW/F+MFOBA==",
"dev": true
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/lodash.merge": {
"version": "4.6.2",
"resolved": "https://registry.npmjs.org/lodash.merge/-/lodash.merge-4.6.2.tgz",
"integrity": "sha512-0KpjqXRVvrYyCsX1swR/XTK0va6VQkQM6MNo7PqW77ByjAhoARA8EfrP1N4+KlKj8YS0ZUCtRT/YUuhyYDujIQ==",
"dev": true
},
"node_modules/lodash.some": {
"version": "4.6.0",
"resolved": "https://registry.npmjs.org/lodash.some/-/lodash.some-4.6.0.tgz",
"integrity": "sha1-G7nzFO9ri63tE7VJFpsqlF62jk0=",
"dev": true
},
"node_modules/lodash.truncate": {
"version": "4.4.2",
"resolved": "https://registry.npmjs.org/lodash.truncate/-/lodash.truncate-4.4.2.tgz",
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"integrity": "sha512-jttmRe7bRse52OsWIMDLaXxWqRAmtIUccAQ3garviCqJjafXOfNMO0yMfNpdD6zbGaTU0P5Nz7e7gAT6cKmJRw==",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dev": true
},
"node_modules/loose-envify": {
"version": "1.4.0",
"resolved": "https://registry.npmjs.org/loose-envify/-/loose-envify-1.4.0.tgz",
"integrity": "sha512-lyuxPGr/Wfhrlem2CL/UcnUc1zcqKAImBDzukY7Y5F/yQiNdko6+fRLevlw1HgMySw7f611UIY408EtxRSoK3Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"peer": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"js-tokens": "^3.0.0 || ^4.0.0"
},
"bin": {
"loose-envify": "cli.js"
}
},
"node_modules/lru-cache": {
"version": "6.0.0",
"resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-6.0.0.tgz",
"integrity": "sha512-Jo6dJ04CmSjuznwJSS3pUeWmd/H0ffTlkXXgwZi+eq1UCmqQwCh+eLsYOYCwY991i2Fah4h1BEMCx4qThGbsiA==",
"dev": true,
"dependencies": {
"yallist": "^4.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=10"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/lru-cache/node_modules/yallist": {
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"version": "4.0.0",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"resolved": "https://registry.npmjs.org/yallist/-/yallist-4.0.0.tgz",
"integrity": "sha512-3wdGidZyq5PB084XLES5TpOSRA3wjXAlIWMhum2kRcv/41Sn2emQ0dycQW4uZXLejwKvg6EsvbdlVL+FYEct7A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/make-dir": {
"version": "3.1.0",
"resolved": "https://registry.npmjs.org/make-dir/-/make-dir-3.1.0.tgz",
"integrity": "sha512-g3FeP20LNwhALb/6Cz6Dd4F2ngze0jz7tbzrD2wAV+o9FeNHe4rL+yK2md0J/fiSf1sa1ADhXqi5+oVwOM/eGw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"semver": "^6.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/make-dir/node_modules/semver": {
Fix dependency vulnerabilities with `npm audit fix`
2023-10-14 13:46:57 +02:00
"version": "6.3.1",
"resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz",
"integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"bin": {
"semver": "bin/semver.js"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/map-cache": {
"version": "0.2.2",
"resolved": "https://registry.npmjs.org/map-cache/-/map-cache-0.2.2.tgz",
"integrity": "sha1-wyq9C9ZSXZsFFkW7TyasXcmKDb8=",
Update npm packages
2022-01-23 10:58:15 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
"node": ">=0.10.0"
Update npm packages
2022-01-23 10:58:15 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/markdown-it": {
"version": "13.0.1",
"resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-13.0.1.tgz",
"integrity": "sha512-lTlxriVoy2criHP0JKRhO2VDG9c2ypWCsT237eDiLqi09rmbKoUetyGHq2uOIRoRS//kfoJckS0eUzzkDR+k2Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"peer": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update npm packages
2022-01-23 10:58:15 +01:00
"argparse": "^2.0.1",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"entities": "~3.0.1",
"linkify-it": "^4.0.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"mdurl": "^1.0.1",
"uc.micro": "^1.0.5"
},
"bin": {
"markdown-it": "bin/markdown-it.js"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/markdown-it-anchor": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"version": "8.6.7",
"resolved": "https://registry.npmjs.org/markdown-it-anchor/-/markdown-it-anchor-8.6.7.tgz",
"integrity": "sha512-FlCHFwNnutLgVTflOYHPW2pPcl2AACqVzExlkGQNsi4CJgqOHN7YTgDd4LuhgN1BFO3TS0vLAruV1Td6dwWPJA==",
Update npm packages
2023-01-28 08:13:13 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"peerDependencies": {
"@types/markdown-it": "*",
"markdown-it": "*"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/markdown-it/node_modules/argparse": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
"integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==",
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"dev": true,
"peer": true
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/marked": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"version": "4.3.0",
"resolved": "https://registry.npmjs.org/marked/-/marked-4.3.0.tgz",
"integrity": "sha512-PRsaiG84bK+AMvxziE/lCFss8juXjNaWzVbN5tXAm4XjeaS9NAHhop+PjQxz2A9h8Q4M/xGmzP8vqNwy6JeK0A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"bin": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"marked": "bin/marked.js"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">= 12"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/mathml-tag-names": {
"version": "2.1.3",
"resolved": "https://registry.npmjs.org/mathml-tag-names/-/mathml-tag-names-2.1.3.tgz",
"integrity": "sha512-APMBEanjybaPzUrfqU0IMU5I0AswKMH7k8OTLs0vvV4KZpExkTkY87nR/zpbuTPj+gARop7aGUbl11pnDfW6xg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"funding": {
"type": "github",
"url": "https://github.com/sponsors/wooorm"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"node_modules/mdn-data": {
"version": "2.0.30",
"resolved": "https://registry.npmjs.org/mdn-data/-/mdn-data-2.0.30.tgz",
"integrity": "sha512-GaqWWShW4kv/G9IEucWScBx9G1/vsFZZJUO+tD26M8J8z3Kw5RDQjaoZe03YAClgeS/SWPOcb4nkFBTEi5DUEA==",
"dev": true
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/mdurl": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/mdurl/-/mdurl-1.0.1.tgz",
"integrity": "sha1-/oWy7HWlkDfyrf7BAP1sYBdhFS4=",
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"dev": true,
"peer": true
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/memory-fs": {
"version": "0.5.0",
"resolved": "https://registry.npmjs.org/memory-fs/-/memory-fs-0.5.0.tgz",
"integrity": "sha512-jA0rdU5KoQMC0e6ppoNRtpp6vjFq6+NY7r8hywnC7V+1Xj/MtHwGIbB1QaK/dunyjWteJzmkpd7ooeWg10T7GA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"errno": "^0.1.3",
"readable-stream": "^2.0.1"
},
"engines": {
"node": ">=4.3.0 <5.0.0 || >=5.10"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/memory-stream": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/memory-stream/-/memory-stream-1.0.0.tgz",
"integrity": "sha512-Wm13VcsPIMdG96dzILfij09PvuS3APtcKNh7M28FsCA/w6+1mjR7hhPmfFNoilX9xU7wTdhsH5lJAm6XNzdtww==",
"dev": true,
"dependencies": {
"readable-stream": "^3.4.0"
}
},
"node_modules/memory-stream/node_modules/readable-stream": {
"version": "3.6.2",
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.2.tgz",
"integrity": "sha512-9u/sniCrY3D5WdsERHzHE4G2YCXqoG5FTHUiCC4SIbr6XcLZBY05ya9EKjYek9O5xOAwjGq+1JdGBAS7Q9ScoA==",
"dev": true,
"dependencies": {
"inherits": "^2.0.3",
"string_decoder": "^1.1.1",
"util-deprecate": "^1.0.1"
},
"engines": {
"node": ">= 6"
}
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node_modules/meow": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "13.2.0",
"resolved": "https://registry.npmjs.org/meow/-/meow-13.2.0.tgz",
"integrity": "sha512-pxQJQzB6djGPXh08dacEloMFopsOqGVRKFPYvPOt9XDZ1HasbgDZA74CJGreSU4G3Ak7EFJGoiH2auq+yXISgA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update Stylelint to the latest version Trying to update Stylelint to version `15.10.1`, and beyond, broke linting. Looking at the changes the issue appears to be that the `bin/stylelint.js` file was replaced with `bin/stylelint.mjs` instead, which our `gulp lint` runner wasn't able to automatically find; see https://github.com/stylelint/stylelint/compare/15.10.0...15.10.1
2023-07-22 11:34:14 +02:00
"engines": {
Update npm packages
2024-01-06 10:09:12 +01:00
"node": ">=18"
Update Stylelint to the latest version Trying to update Stylelint to version `15.10.1`, and beyond, broke linting. Looking at the changes the issue appears to be that the `bin/stylelint.js` file was replaced with `bin/stylelint.mjs` instead, which our `gulp lint` runner wasn't able to automatically find; see https://github.com/stylelint/stylelint/compare/15.10.0...15.10.1
2023-07-22 11:34:14 +02:00
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Update npm packages
2023-12-23 12:29:51 +01:00
"node_modules/merge-stream": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/merge-stream/-/merge-stream-2.0.0.tgz",
"integrity": "sha512-abv/qOcuPfk3URPfDzmZU1LKmuw8kT+0nIHvKrKgFrwifol/doWcdA4ZqsWQ8ENrFKkd67Mfpo/LovbIUsbt3w==",
"dev": true
},
"node_modules/merge2": {
"version": "1.4.1",
"resolved": "https://registry.npmjs.org/merge2/-/merge2-1.4.1.tgz",
"integrity": "sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==",
Update Stylelint to the latest version Trying to update Stylelint to version `15.10.1`, and beyond, broke linting. Looking at the changes the issue appears to be that the `bin/stylelint.js` file was replaced with `bin/stylelint.mjs` instead, which our `gulp lint` runner wasn't able to automatically find; see https://github.com/stylelint/stylelint/compare/15.10.0...15.10.1
2023-07-22 11:34:14 +02:00
"dev": true,
"engines": {
Update npm packages
2023-12-23 12:29:51 +01:00
"node": ">= 8"
Update Stylelint to the latest version Trying to update Stylelint to version `15.10.1`, and beyond, broke linting. Looking at the changes the issue appears to be that the `bin/stylelint.js` file was replaced with `bin/stylelint.mjs` instead, which our `gulp lint` runner wasn't able to automatically find; see https://github.com/stylelint/stylelint/compare/15.10.0...15.10.1
2023-07-22 11:34:14 +02:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith": {
"version": "2.6.3",
"resolved": "https://registry.npmjs.org/metalsmith/-/metalsmith-2.6.3.tgz",
"integrity": "sha512-nql0eDbeDdYY3cz0uDVmwQ/E9XDBAHBf5p3lz+IwZAlUvz72DAd5+F+vl7Fot7I+yQDVK59uB0CL9S+Ts7ELsw==",
Update Stylelint to the latest version Trying to update Stylelint to version `15.10.1`, and beyond, broke linting. Looking at the changes the issue appears to be that the `bin/stylelint.js` file was replaced with `bin/stylelint.mjs` instead, which our `gulp lint` runner wasn't able to automatically find; see https://github.com/stylelint/stylelint/compare/15.10.0...15.10.1
2023-07-22 11:34:14 +02:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"hasInstallScript": true,
"license": "MIT",
Update Stylelint to the latest version Trying to update Stylelint to version `15.10.1`, and beyond, broke linting. Looking at the changes the issue appears to be that the `bin/stylelint.js` file was replaced with `bin/stylelint.mjs` instead, which our `gulp lint` runner wasn't able to automatically find; see https://github.com/stylelint/stylelint/compare/15.10.0...15.10.1
2023-07-22 11:34:14 +02:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"chokidar": "^3.6.0",
"commander": "^10.0.1",
"debug": "^4.3.4",
"gray-matter": "^4.0.3",
"is-utf8": "~0.2.0",
"lodash.clonedeepwith": "^4.5.0",
"micromatch": "^4.0.5",
"stat-mode": "^1.0.0",
"ware": "^1.3.0"
},
"bin": {
"metalsmith": "bin/metalsmith"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=14.18.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith-html-relative": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/metalsmith-html-relative/-/metalsmith-html-relative-2.0.1.tgz",
"integrity": "sha512-+AyV+qiN7zy4jwkItjQKqvN87L5NwCJAXOhuqBRMhIsNp44bDXvwtd3Kof2eYHNNac69XOGvFc6aEU45Ocv2fw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "GPL-3.0-or-later",
"dependencies": {
"cheerio": "^1.0.0-rc.12",
"deepmerge": "^4.3.1",
"minimatch": "^9.0.3"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": "^12.20.0 || ^14.13.1 || >=16.0.0"
},
"peerDependencies": {
"metalsmith": "^2.5.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith-html-relative/node_modules/brace-expansion": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.1.tgz",
"integrity": "sha512-XnAIvQ8eM+kC6aULx6wuQiwVsnzsi9d3WxzV3FpWTGA19F621kwdbsAcFKXgKUHZWsy+mY6iL1sHTxWEFCytDA==",
"dev": true,
"license": "MIT",
"dependencies": {
"balanced-match": "^1.0.0"
}
},
"node_modules/metalsmith-html-relative/node_modules/minimatch": {
"version": "9.0.4",
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.4.tgz",
"integrity": "sha512-KqWh+VchfxcMNRAJjj2tnsSJdNbHsVgnkBhTNrW7AjVo6OvLtxw8zfT9oLw1JSohlFzJ8jCoTgaoXvJ+kHt6fw==",
Update Stylelint to the latest version Trying to update Stylelint to version `15.10.1`, and beyond, broke linting. Looking at the changes the issue appears to be that the `bin/stylelint.js` file was replaced with `bin/stylelint.mjs` instead, which our `gulp lint` runner wasn't able to automatically find; see https://github.com/stylelint/stylelint/compare/15.10.0...15.10.1
2023-07-22 11:34:14 +02:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "ISC",
"dependencies": {
"brace-expansion": "^2.0.1"
},
Update Stylelint to the latest version Trying to update Stylelint to version `15.10.1`, and beyond, broke linting. Looking at the changes the issue appears to be that the `bin/stylelint.js` file was replaced with `bin/stylelint.mjs` instead, which our `gulp lint` runner wasn't able to automatically find; see https://github.com/stylelint/stylelint/compare/15.10.0...15.10.1
2023-07-22 11:34:14 +02:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=16 || 14 >=14.17"
},
"funding": {
"url": "https://github.com/sponsors/isaacs"
Update Stylelint to the latest version Trying to update Stylelint to version `15.10.1`, and beyond, broke linting. Looking at the changes the issue appears to be that the `bin/stylelint.js` file was replaced with `bin/stylelint.mjs` instead, which our `gulp lint` runner wasn't able to automatically find; see https://github.com/stylelint/stylelint/compare/15.10.0...15.10.1
2023-07-22 11:34:14 +02:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/anymatch": {
"version": "3.1.3",
"resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.3.tgz",
"integrity": "sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "ISC",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"normalize-path": "^3.0.0",
"picomatch": "^2.0.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">= 8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/binary-extensions": {
"version": "2.3.0",
"resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.3.0.tgz",
"integrity": "sha512-Ceh+7ox5qe7LJuLHoY0feh3pHuUDHAcRUeyL2VYghZwfpkNIy/+8Ocg0a3UuSoYzavmylwuLWQOf3hl0jjMMIw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/braces": {
"version": "3.0.3",
"resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
"integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
"dependencies": {
"fill-range": "^7.1.1"
},
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=8"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/chokidar": {
"version": "3.6.0",
"resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.6.0.tgz",
"integrity": "sha512-7VT13fmjotKpGipCW9JEQAusEPE+Ei8nl6/g4FBAmIm0GOOLMua9NDDo/DWp0ZAxCr3cPq5ZpBqmPAQgDda2Pw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"anymatch": "~3.1.2",
"braces": "~3.0.2",
"glob-parent": "~5.1.2",
"is-binary-path": "~2.1.0",
"is-glob": "~4.0.1",
"normalize-path": "~3.0.0",
"readdirp": "~3.6.0"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">= 8.10.0"
},
"funding": {
"url": "https://paulmillr.com/funding/"
},
"optionalDependencies": {
"fsevents": "~2.3.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/commander": {
"version": "10.0.1",
"resolved": "https://registry.npmjs.org/commander/-/commander-10.0.1.tgz",
"integrity": "sha512-y4Mg2tXshplEbSGzx7amzPwKKOCGuoSRP/CjEdwwk0FOGlUbq6lKuoyDZTNZkmxHdJtp54hdfY/JUrdL7Xfdug==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
"engines": {
"node": ">=14"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/debug": {
"version": "4.3.5",
"resolved": "https://registry.npmjs.org/debug/-/debug-4.3.5.tgz",
"integrity": "sha512-pt0bNEmneDIvdL1Xsd9oDQ/wrQRkXDT4AUWlNZNPKvW5x/jyO9VFXkJUP07vQ2upmw5PlaITaPKc31jK13V+jg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"ms": "2.1.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=6.0"
},
"peerDependenciesMeta": {
"supports-color": {
"optional": true
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/fill-range": {
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
"integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"to-regex-range": "^5.0.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/glob-parent": {
"version": "5.1.2",
"resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz",
"integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "ISC",
"dependencies": {
"is-glob": "^4.0.1"
},
"engines": {
"node": ">= 6"
}
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/is-binary-path": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz",
"integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"binary-extensions": "^2.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/is-glob": {
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz",
"integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"is-extglob": "^2.1.1"
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=0.10.0"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/is-number": {
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
"integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
Polyfill `Path2D` in Node.js environments Until just recently the only existing `Path2D` polyfill didn't have support for Node.js and/or the `node-canvas` package. Given that this was just fixed, in the latest version, we can now finally remove our inline-checks at the relevant call-sites; please also see https://github.com/nilzona/path2d-polyfill#usage-with-node-canvas
2023-01-22 17:01:06 +01:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=0.12.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/micromatch": {
"version": "4.0.7",
"resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.7.tgz",
"integrity": "sha512-LPP/3KorzCwBxfeUuZmaR6bG2kdeHSbe0P2tY3FLRU4vYrjYz5hI4QZwV0njUx3jeuKe67YukQ1LSPZBKDqO/Q==",
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
"dependencies": {
"braces": "^3.0.3",
"picomatch": "^2.3.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=8.6"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/normalize-path": {
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"version": "3.0.0",
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz",
"integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"license": "MIT",
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"engines": {
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/readdirp": {
"version": "3.6.0",
"resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.6.0.tgz",
"integrity": "sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"license": "MIT",
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"picomatch": "^2.2.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=8.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/metalsmith/node_modules/to-regex-range": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
"integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"license": "MIT",
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"is-number": "^7.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=8.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/mime-db": {
"version": "1.51.0",
"resolved": "https://registry.npmjs.org/mime-db/-/mime-db-1.51.0.tgz",
"integrity": "sha512-5y8A56jg7XVQx2mbv1lu49NR4dokRnhZYTtL+KGfaa27uq4pSTXkwQkFJl4pkRMyNFz/EtYDSkiiEHx3F7UN6g==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"engines": {
"node": ">= 0.6"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/mime-types": {
"version": "2.1.34",
"resolved": "https://registry.npmjs.org/mime-types/-/mime-types-2.1.34.tgz",
"integrity": "sha512-6cP692WwGIs9XXdOO4++N+7qjqv0rqxxVvJ3VHPh/Sc9mVZcQP+ZGhkKiTvWMQRr2tbHkJP/Yn7Y0npb3ZBs4A==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"mime-db": "1.51.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">= 0.6"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/mimic-response": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/mimic-response/-/mimic-response-2.1.0.tgz",
"integrity": "sha512-wXqjST+SLt7R009ySCglWBCFpjUygmCIfD790/kVbiGmUgfYGuB14PiTd5DwVxSV4NcYHjzMkoj5LjQZwTQLEA==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/min-indent": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/min-indent/-/min-indent-1.0.1.tgz",
"integrity": "sha512-I9jwMn07Sy/IwOj3zVkVik2JTvgpaykDZEigL6Rx6N9LbMywwUSMtxET+7lVoDLLd3O3IXwJwvuuns8UB/HeAg==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=4"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/minimatch": {
"version": "3.1.2",
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz",
"integrity": "sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"brace-expansion": "^1.1.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": "*"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/minimist": {
"version": "1.2.8",
"resolved": "https://registry.npmjs.org/minimist/-/minimist-1.2.8.tgz",
"integrity": "sha512-2yyAR8qBkN3YuheJanUpWC5U3bb5osDywNB8RzDVlDwDHbocAJveqqj1u8+SVD7jkWT4yvsHCpWqqWqAxb0zCA==",
"dev": true,
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/minipass": {
"version": "3.1.3",
"resolved": "https://registry.npmjs.org/minipass/-/minipass-3.1.3.tgz",
"integrity": "sha512-Mgd2GdMVzY+x3IJ+oHnVM+KG3lA5c8tnabyJKmHSaG2kAGpudxuOf8ToDkhumF7UzME7DecbQE9uOZhNm7PuJg==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"yallist": "^4.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/minipass/node_modules/yallist": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/yallist/-/yallist-4.0.0.tgz",
"integrity": "sha512-3wdGidZyq5PB084XLES5TpOSRA3wjXAlIWMhum2kRcv/41Sn2emQ0dycQW4uZXLejwKvg6EsvbdlVL+FYEct7A==",
"dev": true
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/minizlib": {
"version": "2.1.2",
"resolved": "https://registry.npmjs.org/minizlib/-/minizlib-2.1.2.tgz",
"integrity": "sha512-bAxsR8BVfj60DWXHE3u30oHzfl4G7khkSuPW+qvpd7jFRHm7dLxOjUk1EHACJ/hxLY8phGJ0YhYHZo7jil7Qdg==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"minipass": "^3.0.0",
"yallist": "^4.0.0"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">= 8"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/minizlib/node_modules/yallist": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/yallist/-/yallist-4.0.0.tgz",
"integrity": "sha512-3wdGidZyq5PB084XLES5TpOSRA3wjXAlIWMhum2kRcv/41Sn2emQ0dycQW4uZXLejwKvg6EsvbdlVL+FYEct7A==",
"dev": true
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/mitt": {
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/mitt/-/mitt-3.0.1.tgz",
"integrity": "sha512-vKivATfr97l2/QBCYAkXYDbrIWPM2IIKEl7YPhjCvKlG3kE2gm+uBo6nEXK3M5/Ffh/FLpKExzOQ3JJoJGFKBw==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/mkdirp-classic": {
"version": "0.5.3",
"resolved": "https://registry.npmjs.org/mkdirp-classic/-/mkdirp-classic-0.5.3.tgz",
"integrity": "sha512-gKLcREMhtuZRwRAfqP3RFW+TK4JqApVBtOIftVgjuABpAtpxhPGaDcfvbhNvD0B8iD1oUr/txX35NjcaY6Ns/A==",
"dev": true
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"node_modules/ms": {
"version": "2.1.2",
"resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz",
"integrity": "sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==",
"dev": true,
"license": "MIT"
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/mute-stdout": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/mute-stdout/-/mute-stdout-2.0.0.tgz",
"integrity": "sha512-32GSKM3Wyc8dg/p39lWPKYu8zci9mJFzV1Np9Of0ZEpe6Fhssn/FbI7ywAMd40uX+p3ZKh3T5EeCFv81qS3HmQ==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"engines": {
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/mylas": {
"version": "2.1.13",
"resolved": "https://registry.npmjs.org/mylas/-/mylas-2.1.13.tgz",
"integrity": "sha512-+MrqnJRtxdF+xngFfUUkIMQrUUL0KsxbADUkn23Z/4ibGg192Q+z+CQyiYwvWTsYjJygmMR8+w3ZDa98Zh6ESg==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"engines": {
"node": ">=12.0.0"
},
"funding": {
"type": "github",
"url": "https://github.com/sponsors/raouldeheer"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/nan": {
"version": "2.17.0",
"resolved": "https://registry.npmjs.org/nan/-/nan-2.17.0.tgz",
"integrity": "sha512-2ZTgtl0nJsO0KQCjEpxcIr5D+Yv90plTitZt9JBfQvVJDS5seMl3FOvsh3+9CoYWXf/1l5OaZzzF6nDm4cagaQ==",
"dev": true
},
"node_modules/nanoid": {
"version": "3.3.7",
"resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.3.7.tgz",
"integrity": "sha512-eSRppjcPIatRIMC1U6UngP8XFcz8MQWGQdt1MTBQ7NaAmvXDfvNxbvWV3x2y6CdEUciCSsDHDQZbhYaB8QEo2g==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/ai"
}
],
"bin": {
"nanoid": "bin/nanoid.cjs"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": "^10 || ^12 || ^13.7 || ^14 || >=15.0.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/napi-build-utils": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/napi-build-utils/-/napi-build-utils-1.0.2.tgz",
"integrity": "sha512-ONmRUqK7zj7DWX0D9ADe03wbwOBZxNAfF20PlGfCWQcD3+/MakShIHrMqx9YwPTfxDdF1zLeL+RGZiR9kGMLdg==",
"dev": true
},
"node_modules/natural-compare": {
"version": "1.4.0",
"resolved": "https://registry.npmjs.org/natural-compare/-/natural-compare-1.4.0.tgz",
"integrity": "sha1-Sr6/7tdUHywnrPspvbvRXI1bpPc=",
"dev": true
},
"node_modules/neo-async": {
"version": "2.6.2",
"resolved": "https://registry.npmjs.org/neo-async/-/neo-async-2.6.2.tgz",
"integrity": "sha512-Yd3UES5mWCSqR+qNT93S3UoYUkqAZ9lLg8a7g9rimsWmYGK8cVToA4/sF3RrshdyV3sAGMXVUmpMYOw+dLpOuw==",
"dev": true
},
"node_modules/netmask": {
"version": "2.0.2",
"resolved": "https://registry.npmjs.org/netmask/-/netmask-2.0.2.tgz",
"integrity": "sha512-dBpDMdxv9Irdq66304OLfEmQ9tbNRFnFTuZiLo+bD+r332bBmMJ8GBLXklIXXgxd3+v9+KUnZaUR5PJMa75Gsg==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"license": "MIT",
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">= 0.4.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/node-abi": {
"version": "3.51.0",
"resolved": "https://registry.npmjs.org/node-abi/-/node-abi-3.51.0.tgz",
"integrity": "sha512-SQkEP4hmNWjlniS5zdnfIXTk1x7Ome85RDzHlTbBtzE97Gfwz/Ipw4v/Ryk20DWIy3yCNVLVlGKApCnmvYoJbA==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"semver": "^7.3.5"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=10"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/node-abi/node_modules/semver": {
"version": "7.5.4",
"resolved": "https://registry.npmjs.org/semver/-/semver-7.5.4.tgz",
"integrity": "sha512-1bCSESV6Pv+i21Hvpxp3Dx+pSD8lIPt8uVjRrxAUt/nbswYc+tK6Y2btiULjd4+fnq15PX+nqQDC7Oft7WkwcA==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"lru-cache": "^6.0.0"
},
"bin": {
"semver": "bin/semver.js"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=10"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/node-addon-api": {
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/node-addon-api/-/node-addon-api-7.0.0.tgz",
"integrity": "sha512-vgbBJTS4m5/KkE16t5Ly0WW9hz46swAstv0hYYwMtbG7AznRhNyfLRe8HZAiWIpcHzoO7HxhLuBQj9rJ/Ho0ZA==",
"dev": true
},
"node_modules/node-api-headers": {
"version": "0.0.2",
"resolved": "https://registry.npmjs.org/node-api-headers/-/node-api-headers-0.0.2.tgz",
"integrity": "sha512-YsjmaKGPDkmhoNKIpkChtCsPVaRE0a274IdERKnuc/E8K1UJdBZ4/mvI006OijlQZHCfpRNOH3dfHQs92se8gg==",
"dev": true
},
"node_modules/node-fetch": {
"version": "2.6.12",
"resolved": "https://registry.npmjs.org/node-fetch/-/node-fetch-2.6.12.tgz",
"integrity": "sha512-C/fGU2E8ToujUivIO0H+tpQ6HWo4eEmchoPIoXtxCrVghxdKq+QOHqEZW7tuP3KlV3bC8FRMO5nMCC7Zm1VP6g==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"whatwg-url": "^5.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": "4.x || >=6.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"peerDependencies": {
"encoding": "^0.1.0"
},
"peerDependenciesMeta": {
"encoding": {
"optional": true
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/node-releases": {
"version": "2.0.14",
"resolved": "https://registry.npmjs.org/node-releases/-/node-releases-2.0.14.tgz",
"integrity": "sha512-y10wOWt8yZpqXmOgRo77WaHEmhYQYGNA6y421PKsKYWEK8aW+cqAphborZDhqfyKrbZEN92CN1X2KbafY2s7Yw==",
"dev": true
},
"node_modules/nopt": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/nopt/-/nopt-5.0.0.tgz",
"integrity": "sha512-Tbj67rffqceeLpcRXrT7vKAN8CwfPeIBgM7E6iBkmKLV7bEMwpGgYLGv0jACUsECaa/vuxP0IjEont6umdMgtQ==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"abbrev": "1"
},
"bin": {
"nopt": "bin/nopt.js"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=6"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/normalize-package-data": {
"version": "2.5.0",
"resolved": "https://registry.npmjs.org/normalize-package-data/-/normalize-package-data-2.5.0.tgz",
"integrity": "sha512-/5CMN3T0R4XTj4DcGaexo+roZSdSFW/0AOOTROrjxzCG1wrWXEsGbRKevjlIL+ZDE4sZlJr5ED4YW0yqmkK+eA==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"dependencies": {
"hosted-git-info": "^2.1.4",
"resolve": "^1.10.0",
"semver": "2 || 3 || 4 || 5",
"validate-npm-package-license": "^3.0.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/normalize-range": {
"version": "0.1.2",
"resolved": "https://registry.npmjs.org/normalize-range/-/normalize-range-0.1.2.tgz",
"integrity": "sha1-LRDAa9/TEuqXd2laTShDlFa3WUI=",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=0.10.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/now-and-later": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/now-and-later/-/now-and-later-3.0.0.tgz",
"integrity": "sha512-pGO4pzSdaxhWTGkfSfHx3hVzJVslFPwBp2Myq9MYN/ChfJZF87ochMAXnvz6/58RJSf5ik2q9tXprBBrk2cpcg==",
Update npm packages
2023-02-11 10:24:22 +01:00
"dev": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"license": "MIT",
"dependencies": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"once": "^1.4.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/npmlog": {
"version": "4.1.2",
"resolved": "https://registry.npmjs.org/npmlog/-/npmlog-4.1.2.tgz",
"integrity": "sha512-2uUqazuKlTaSI/dC8AzicUck7+IrEaOnN/e0jd3Xtt1KcGpwx30v50mL7oPyr/h9bL3E4aZccVwpwP+5W9Vjkg==",
"dev": true,
"dependencies": {
"are-we-there-yet": "~1.1.2",
"console-control-strings": "~1.1.0",
"gauge": "~2.7.3",
"set-blocking": "~2.0.0"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/nth-check": {
"version": "2.1.1",
"resolved": "https://registry.npmjs.org/nth-check/-/nth-check-2.1.1.tgz",
"integrity": "sha512-lqjrjmaOoAnWfMmBPL+XNnynZh2+swxiX3WUE0s4yEHI6m+AwrK2UZOimIRl3X/4QctVqS8AiZjFqyOGrMXb/w==",
"dev": true,
"license": "BSD-2-Clause",
"dependencies": {
"boolbase": "^1.0.0"
},
"funding": {
"url": "https://github.com/fb55/nth-check?sponsor=1"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/number-is-nan": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/number-is-nan/-/number-is-nan-1.0.1.tgz",
"integrity": "sha1-CXtgK1NCKlIsGvuHkDGDNpQaAR0=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/object-assign": {
"version": "4.1.1",
"resolved": "https://registry.npmjs.org/object-assign/-/object-assign-4.1.1.tgz",
"integrity": "sha1-IQmtx5ZYh8/AXLvUQsrIv7s2CGM=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/object-inspect": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "1.12.3",
"resolved": "https://registry.npmjs.org/object-inspect/-/object-inspect-1.12.3.tgz",
"integrity": "sha512-geUvdk7c+eizMNUDkRpW1wJwgfOiOeHbxBR/hLXK1aT6zmVSO0jsQcs7fj6MGw89jC/cjGfLcNOrtMYtGqm81g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/object-keys": {
Update npm packages
2022-09-18 10:31:32 +02:00
"version": "1.1.1",
"resolved": "https://registry.npmjs.org/object-keys/-/object-keys-1.1.1.tgz",
"integrity": "sha512-NuAESUOUMrlIXOfHKzD6bpPu3tYt3xvjNdRIQ+FeT0lNb4K8WR70CaDxhuNguS2XG+GjkyMwOzsN5ZktImfhLA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">= 0.4"
}
},
"node_modules/object.assign": {
Update npm packages
2022-09-18 10:31:32 +02:00
"version": "4.1.4",
"resolved": "https://registry.npmjs.org/object.assign/-/object.assign-4.1.4.tgz",
"integrity": "sha512-1mxKf0e58bvyjSCtKYY4sRe9itRk3PJpquJOjeIkz885CczcI4IvJJDLPS72oowuSh+pBxUFROpX+TU++hxhZQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2022-09-18 10:31:32 +02:00
"call-bind": "^1.0.2",
"define-properties": "^1.1.4",
"has-symbols": "^1.0.3",
"object-keys": "^1.1.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">= 0.4"
Update npm packages
2022-09-18 10:31:32 +02:00
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/object.defaults": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/object.defaults/-/object.defaults-1.1.0.tgz",
"integrity": "sha1-On+GgzS0B96gbaFtiNXNKeQ1/s8=",
"dev": true,
"dependencies": {
"array-each": "^1.0.1",
"array-slice": "^1.0.0",
"for-own": "^1.0.0",
"isobject": "^3.0.0"
},
"engines": {
"node": ">=0.10.0"
}
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/object.entries": {
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"version": "1.1.7",
"resolved": "https://registry.npmjs.org/object.entries/-/object.entries-1.1.7.tgz",
"integrity": "sha512-jCBs/0plmPsOnrKAfFQXRG2NFjlhZgjjcBLSmTnEhU8U6vVTsVe8ANeQJCHTl3gSsI4J+0emOoCgoKlmQPMgmA==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true,
"peer": true,
"dependencies": {
"call-bind": "^1.0.2",
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"define-properties": "^1.2.0",
"es-abstract": "^1.22.1"
Update npm packages
2022-09-18 10:31:32 +02:00
},
"engines": {
"node": ">= 0.4"
}
},
"node_modules/object.fromentries": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"version": "2.0.7",
"resolved": "https://registry.npmjs.org/object.fromentries/-/object.fromentries-2.0.7.tgz",
"integrity": "sha512-UPbPHML6sL8PI/mOqPwsH4G6iyXcCGzLin8KvEPenOZN5lpCNBZZQ+V62vdjB1mQHrmqGQt5/OJzemUA+KJmEA==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"define-properties": "^1.2.0",
"es-abstract": "^1.22.1"
Update npm packages
2022-09-18 10:31:32 +02:00
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Update npm packages
2023-08-06 09:22:20 +02:00
"node_modules/object.groupby": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/object.groupby/-/object.groupby-1.0.1.tgz",
"integrity": "sha512-HqaQtqLnp/8Bn4GL16cj+CUYbnpe1bh0TtEaWvybszDG4tgxCJuRpV8VGuvNaI1fAnI4lUJzDG55MXcOH4JZcQ==",
Update npm packages
2023-08-06 09:22:20 +02:00
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
"define-properties": "^1.2.0",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"es-abstract": "^1.22.1",
Update npm packages
2023-08-06 09:22:20 +02:00
"get-intrinsic": "^1.2.1"
}
},
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"node_modules/object.hasown": {
"version": "1.1.3",
"resolved": "https://registry.npmjs.org/object.hasown/-/object.hasown-1.1.3.tgz",
"integrity": "sha512-fFI4VcYpRHvSLXxP7yiZOMAd331cPfd2p7PFDVbgUsYOfCT3tICVqXWngbjr4m49OvsBwUBQ6O2uQoJvy3RexA==",
"dev": true,
"peer": true,
"dependencies": {
"define-properties": "^1.2.0",
"es-abstract": "^1.22.1"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/object.pick": {
"version": "1.3.0",
"resolved": "https://registry.npmjs.org/object.pick/-/object.pick-1.3.0.tgz",
"integrity": "sha1-h6EKxMFpS9Lhy/U1kaZhQftd10c=",
"dev": true,
"dependencies": {
"isobject": "^3.0.1"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/object.values": {
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"version": "1.1.7",
"resolved": "https://registry.npmjs.org/object.values/-/object.values-1.1.7.tgz",
"integrity": "sha512-aU6xnDFYT3x17e/f0IiiwlGPTy2jzMySGfUB4fq6z7CV8l85CWHDk5ErhyhpfDHhrOMwGFhSQkhMGHaIotA6Ng==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"define-properties": "^1.2.0",
"es-abstract": "^1.22.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/once": {
"version": "1.4.0",
"resolved": "https://registry.npmjs.org/once/-/once-1.4.0.tgz",
"integrity": "sha1-WDsap3WWHUsROsF9nFC6753Xa9E=",
"dev": true,
"dependencies": {
"wrappy": "1"
}
},
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"node_modules/ordered-read-streams": {
Remove the `merge-stream` dependency in favor of the `ordered-read-streams` dependency The `merge-stream` dependency is no longer maintained and doesn't work in combination with Gulp 5 anymore (for more information refer to https://github.com/gulpjs/gulp/issues/2802#issuecomment-2094130656). Fortunately the Gulp team maintains a drop-in replacement dependency called `ordered-read-streams` with the same API as `merge-stream`. Indeed, running all affected Gulp targets and comparing build artifacts with `diff -r <old> <new>` confirms that no unexpected changes are made. Fixes a part of #17922.
2024-05-22 14:11:58 +02:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/ordered-read-streams/-/ordered-read-streams-2.0.0.tgz",
"integrity": "sha512-YT9wHHV9mB/qadhWnBsC57JKhAMA22/aR+RwZRgcf4K4Q7IIfmSsnYGxgiu9LVZP3wddRAm5pfYkzkmBb+HuwA==",
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"dev": true,
Remove the `merge-stream` dependency in favor of the `ordered-read-streams` dependency The `merge-stream` dependency is no longer maintained and doesn't work in combination with Gulp 5 anymore (for more information refer to https://github.com/gulpjs/gulp/issues/2802#issuecomment-2094130656). Fortunately the Gulp team maintains a drop-in replacement dependency called `ordered-read-streams` with the same API as `merge-stream`. Indeed, running all affected Gulp targets and comparing build artifacts with `diff -r <old> <new>` confirms that no unexpected changes are made. Fixes a part of #17922.
2024-05-22 14:11:58 +02:00
"license": "MIT",
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"dependencies": {
Remove the `merge-stream` dependency in favor of the `ordered-read-streams` dependency The `merge-stream` dependency is no longer maintained and doesn't work in combination with Gulp 5 anymore (for more information refer to https://github.com/gulpjs/gulp/issues/2802#issuecomment-2094130656). Fortunately the Gulp team maintains a drop-in replacement dependency called `ordered-read-streams` with the same API as `merge-stream`. Indeed, running all affected Gulp targets and comparing build artifacts with `diff -r <old> <new>` confirms that no unexpected changes are made. Fixes a part of #17922.
2024-05-22 14:11:58 +02:00
"streamx": "^2.12.5"
},
"engines": {
"node": ">= 10.13.0"
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
}
},
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node_modules/p-limit": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/p-limit/-/p-limit-4.0.0.tgz",
"integrity": "sha512-5b0R4txpzjPWVw/cXXUResoD4hb6U/x9BH08L7nw+GN1sezDzPdxeRvpc9c433fZhBan/wusjbCsqwqm4EIBIQ==",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dev": true,
"dependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"yocto-queue": "^1.0.0"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
},
"engines": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node": "^12.20.0 || ^14.13.1 || >=16.0.0"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
},
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
}
},
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node_modules/p-limit/node_modules/yocto-queue": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/yocto-queue/-/yocto-queue-1.0.0.tgz",
"integrity": "sha512-9bnSc/HEW2uRy67wc+T8UwauLuPJVn28jb+GtJY16iiKWyvmYJRXVT4UamsAEGQfPohgr2q4Tq0sQbQlxTfi1g==",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dev": true,
"engines": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node": ">=12.20"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
},
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
}
},
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node_modules/p-locate": {
"version": "6.0.0",
"resolved": "https://registry.npmjs.org/p-locate/-/p-locate-6.0.0.tgz",
"integrity": "sha512-wPrq66Llhl7/4AGC6I+cqxT07LhXvWL08LNXz1fENOw0Ap4sRZZ/gZpTTJ5jpurzzzfS2W/Ge9BY3LgLjCShcw==",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dev": true,
"dependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"p-limit": "^4.0.0"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
},
"engines": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node": "^12.20.0 || ^14.13.1 || >=16.0.0"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
},
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
}
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/pac-proxy-agent": {
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/pac-proxy-agent/-/pac-proxy-agent-7.0.2.tgz",
"integrity": "sha512-BFi3vZnO9X5Qt6NRz7ZOaPja3ic0PhlsmCRYLOpN11+mWBCR6XJDqW5RF3j8jm4WGGQZtBA+bTfxYzeKW73eHg==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"@tootallnate/quickjs-emscripten": "^0.23.0",
"agent-base": "^7.0.2",
"debug": "^4.3.4",
"get-uri": "^6.0.1",
"http-proxy-agent": "^7.0.0",
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"https-proxy-agent": "^7.0.5",
"pac-resolver": "^7.0.1",
"socks-proxy-agent": "^8.0.4"
Update npm packages
2023-07-23 09:49:53 +02:00
},
"engines": {
"node": ">= 14"
}
},
"node_modules/pac-proxy-agent/node_modules/agent-base": {
Update dependencies to the most recent versions
2024-04-03 14:42:19 +02:00
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/agent-base/-/agent-base-7.1.1.tgz",
"integrity": "sha512-H0TSyFNDMomMNJQBn8wFV5YC/2eJ+VXECwOadZJT554xP6cODZHPX3H9QMQECxvrgiSOP1pHjy1sMWQVYJOUOA==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"debug": "^4.3.4"
},
"engines": {
"node": ">= 14"
}
},
"node_modules/pac-proxy-agent/node_modules/https-proxy-agent": {
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"version": "7.0.5",
"resolved": "https://registry.npmjs.org/https-proxy-agent/-/https-proxy-agent-7.0.5.tgz",
"integrity": "sha512-1e4Wqeblerz+tMKPIq2EMGiiWW1dIjZOksyHWSUm1rmuvw/how9hBHZ38lAGj5ID4Ik6EdkOw7NmWPy6LAwalw==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"agent-base": "^7.0.2",
"debug": "4"
},
"engines": {
"node": ">= 14"
}
},
"node_modules/pac-resolver": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"version": "7.0.1",
"resolved": "https://registry.npmjs.org/pac-resolver/-/pac-resolver-7.0.1.tgz",
"integrity": "sha512-5NPgf87AT2STgwa2ntRMr45jTKrYBGkVU36yT0ig/n/GMAa3oPqhZfIQ2kMEimReg0+t9kZViDVZ83qfVUlckg==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"degenerator": "^5.0.0",
"netmask": "^2.0.2"
},
"engines": {
"node": ">= 14"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/parent-module": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/parent-module/-/parent-module-1.0.1.tgz",
"integrity": "sha512-GQ2EWRpQV8/o+Aw8YqtfZZPfNRWZYkbidE9k5rpl/hC3vtHHBfGm2Ifi6qWV+coDGkrUKZAxE3Lot5kcsRlh+g==",
"dev": true,
"dependencies": {
"callsites": "^3.0.0"
},
"engines": {
"node": ">=6"
}
},
"node_modules/parse-filepath": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/parse-filepath/-/parse-filepath-1.0.2.tgz",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"integrity": "sha512-FwdRXKCohSVeXqwtYonZTXtbGJKrn+HNyWDYVcp5yuJlesTwNH4rsmRZ+GrKAPJ5bLpRxESMeS+Rl0VCHRvB2Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"is-absolute": "^1.0.0",
"map-cache": "^0.2.0",
"path-root": "^0.1.1"
},
"engines": {
"node": ">=0.8"
}
},
"node_modules/parse-node-version": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/parse-node-version/-/parse-node-version-1.0.0.tgz",
"integrity": "sha512-02GTVHD1u0nWc20n2G7WX/PgdhNFG04j5fi1OkaJzPWLTcf6vh6229Lta1wTmXG/7Dg42tCssgkccVt7qvd8Kg==",
"dev": true,
"engines": {
"node": ">= 0.10"
}
},
"node_modules/parse-passwd": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/parse-passwd/-/parse-passwd-1.0.0.tgz",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"integrity": "sha512-1Y1A//QUXEZK7YKz+rD9WydcE1+EuPr6ZBgKecAB8tmoW6UFv0NREVJe1p+jRxtThkcbbKkfwIbWJe/IeE6m2Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/parse5": {
"version": "7.1.2",
"resolved": "https://registry.npmjs.org/parse5/-/parse5-7.1.2.tgz",
"integrity": "sha512-Czj1WaSVpaoj0wbhMzLmWD69anp2WH7FXMB9n1Sy8/ZFF9jolSQVMu1Ij5WIyGmcBmhk7EOndpO4mIpihVqAXw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
"dependencies": {
"entities": "^4.4.0"
},
"funding": {
"url": "https://github.com/inikulin/parse5?sponsor=1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/parse5-htmlparser2-tree-adapter": {
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/parse5-htmlparser2-tree-adapter/-/parse5-htmlparser2-tree-adapter-7.0.0.tgz",
"integrity": "sha512-B77tOZrqqfUfnVcOrUvfdLbz4pu4RopLD/4vmu3HUPswwTA8OH0EMW9BlWR2B0RCoiZRAHEUu7IxeP1Pd1UU+g==",
"dev": true,
"license": "MIT",
"dependencies": {
"domhandler": "^5.0.2",
"parse5": "^7.0.0"
},
"funding": {
"url": "https://github.com/inikulin/parse5?sponsor=1"
}
},
"node_modules/parse5/node_modules/entities": {
"version": "4.5.0",
"resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz",
"integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==",
"dev": true,
"license": "BSD-2-Clause",
"engines": {
"node": ">=0.12"
},
"funding": {
"url": "https://github.com/fb55/entities?sponsor=1"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node_modules/path-exists": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/path-exists/-/path-exists-5.0.0.tgz",
"integrity": "sha512-RjhtfwJOxzcFmNOi6ltcbcu4Iu+FL3zEj83dk4kAS+fVpTxXLO1b38RvJgT/0QwvV/L3aY9TAnyv0EOqW4GoMQ==",
"dev": true,
"engines": {
"node": "^12.20.0 || ^14.13.1 || >=16.0.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/path-is-absolute": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/path-is-absolute/-/path-is-absolute-1.0.1.tgz",
"integrity": "sha1-F0uSaHNVNP+8es5r9TpanhtcX18=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/path-parse": {
"version": "1.0.7",
"resolved": "https://registry.npmjs.org/path-parse/-/path-parse-1.0.7.tgz",
"integrity": "sha512-LDJzPVEEEPR+y48z93A0Ed0yXb8pAByGWo/k5YYdYgpY2/2EsOsksJrq7lOHxryrVOn1ejG6oAp8ahvOIQD8sw==",
"dev": true
},
"node_modules/path-root": {
"version": "0.1.1",
"resolved": "https://registry.npmjs.org/path-root/-/path-root-0.1.1.tgz",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"integrity": "sha512-QLcPegTHF11axjfojBIoDygmS2E3Lf+8+jI6wOVmNVenrKSo3mFdSGiIgdSHenczw3wPtlVMQaFVwGmM7BJdtg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"path-root-regex": "^0.1.0"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/path-root-regex": {
"version": "0.1.2",
"resolved": "https://registry.npmjs.org/path-root-regex/-/path-root-regex-0.1.2.tgz",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"integrity": "sha512-4GlJ6rZDhQZFE0DPVKh0e9jmZ5egZfxTkp7bcRDuPlJXbAwhxcl2dINPUAsjLdejqaLsCeg8axcLjIbvBjN4pQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node_modules/path-scurry": {
Update npm packages
2024-01-06 10:09:12 +01:00
"version": "1.10.1",
"resolved": "https://registry.npmjs.org/path-scurry/-/path-scurry-1.10.1.tgz",
"integrity": "sha512-MkhCqzzBEpPvxxQ71Md0b1Kk51W01lrYvlMzSUaIzNsODdd7mqhiimSZlr+VegAz5Z6Vzt9Xg2ttE//XBhH3EQ==",
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"dev": true,
"dependencies": {
Update npm packages
2024-01-06 10:09:12 +01:00
"lru-cache": "^9.1.1 || ^10.0.0",
"minipass": "^5.0.0 || ^6.0.2 || ^7.0.0"
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
},
"engines": {
"node": ">=16 || 14 >=14.17"
},
"funding": {
"url": "https://github.com/sponsors/isaacs"
}
},
"node_modules/path-scurry/node_modules/lru-cache": {
"version": "9.1.1",
"resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-9.1.1.tgz",
"integrity": "sha512-65/Jky17UwSb0BuB9V+MyDpsOtXKmYwzhyl+cOa9XUiI4uV2Ouy/2voFP3+al0BjZbJgMBD8FojMpAf+Z+qn4A==",
"dev": true,
"engines": {
"node": "14 || >=16.14"
}
},
"node_modules/path-scurry/node_modules/minipass": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/minipass/-/minipass-5.0.0.tgz",
"integrity": "sha512-3FnjYuehv9k6ovOEbyOswadCDPX1piCfhV8ncmYtHOjuPwylVWsghTLo7rabjC3Rx5xD4HDx8Wm1xnMF7S5qFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/path-type": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/path-type/-/path-type-4.0.0.tgz",
"integrity": "sha512-gDKb8aZMDeD/tZWs9P6+q0J9Mwkdl6xMV8TjnGP3qJVJ06bdMgkbBlLU8IdfOsIsFz2BW1rNVT3XuNEl8zPAvw==",
"dev": true,
"engines": {
"node": ">=8"
}
},
Update npm packages
2024-03-17 13:50:21 +01:00
"node_modules/path2d": {
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"version": "0.2.1",
"resolved": "https://registry.npmjs.org/path2d/-/path2d-0.2.1.tgz",
"integrity": "sha512-Fl2z/BHvkTNvkuBzYTpTuirHZg6wW9z8+4SND/3mDTEcYbbNKWAy21dz9D3ePNNwrrK8pqZO5vLPZ1hLF6T7XA==",
Update npm packages
2024-03-17 13:50:21 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"license": "MIT",
Update npm packages
2024-03-17 13:50:21 +01:00
"engines": {
"node": ">=6"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/pend": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/pend/-/pend-1.2.0.tgz",
Update npm packages
2022-10-16 09:09:38 +02:00
"integrity": "sha512-F3asv42UuXchdzt+xXqfW1OGlVBe+mxa2mqI0pg5yAHZPvFmY3Y6drSf/GQ1A86WgWEN9Kzh/WrgKa6iGcHXLg==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "MIT"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"node_modules/picocolors": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.0.1.tgz",
"integrity": "sha512-anP1Z8qwhkbmu7MFP5iTt+wQKXgwzf7zTyGlcdzabySa9vd0Xt392U0rVmz9poOaBj0uHJKyyo9/upk0HrEQew==",
"dev": true,
"license": "ISC"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"node_modules/picomatch": {
Update npm packages
2022-04-17 10:15:10 +02:00
"version": "2.3.1",
"resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.1.tgz",
"integrity": "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=8.6"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"funding": {
"url": "https://github.com/sponsors/jonschlinkert"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/pkg-dir": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/pkg-dir/-/pkg-dir-7.0.0.tgz",
"integrity": "sha512-Ie9z/WINcxxLp27BKOCHGde4ITq9UklYKDzVo1nhk5sqGEXU3FpkwP5GM2voTGJkGd9B3Otl+Q4uwSOeSUtOBA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"find-up": "^6.3.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node": ">=14.16"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"node_modules/plimit-lit": {
"version": "1.5.0",
"resolved": "https://registry.npmjs.org/plimit-lit/-/plimit-lit-1.5.0.tgz",
"integrity": "sha512-Eb/MqCb1Iv/ok4m1FqIXqvUKPISufcjZ605hl3KM/n8GaX8zfhtgdLwZU3vKjuHGh2O9Rjog/bHTq8ofIShdng==",
"dev": true,
"dependencies": {
"queue-lit": "^1.5.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/plugin-error": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/plugin-error/-/plugin-error-1.0.1.tgz",
"integrity": "sha512-L1zP0dk7vGweZME2i+EeakvUNqSrdiI3F91TwEoYiGrAfUXmVv6fJIq4g82PAXxNsWOp0J7ZqQy/3Szz0ajTxA==",
"dev": true,
"dependencies": {
"ansi-colors": "^1.0.1",
"arr-diff": "^4.0.0",
"arr-union": "^3.1.0",
"extend-shallow": "^3.0.2"
},
"engines": {
"node": ">= 0.10"
}
},
"node_modules/pluralize": {
"version": "8.0.0",
"resolved": "https://registry.npmjs.org/pluralize/-/pluralize-8.0.0.tgz",
"integrity": "sha512-Nc3IT5yHzflTfbjgqWcCPpo7DaKy4FnpB0l/zCAW0Tc7jxAiuqSxHasntB3D7887LSrA93kDJ9IXovxJYxyLCA==",
"dev": true,
"engines": {
"node": ">=4"
}
},
[Editor] Try to make the position of an edited FreeText the more accurated as possible - Take into account the page translation, - Take into account the correct translation for the editor border, - Take into account the position of the first glyph in the annotation, - Take into account the rotation of the editor. Close #16633.
2023-07-05 19:46:21 +02:00
"node_modules/pngjs": {
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/pngjs/-/pngjs-7.0.0.tgz",
"integrity": "sha512-LKWqWJRhstyYo9pGvgor/ivk2w94eSjE3RGVuzLGlr3NmD8bf7RcYGze1mNdEHRP6TRP6rMuDHk5t44hnTRyow==",
"dev": true,
"engines": {
"node": ">=14.19.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/postcss": {
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"version": "8.4.39",
"resolved": "https://registry.npmjs.org/postcss/-/postcss-8.4.39.tgz",
"integrity": "sha512-0vzE+lAiG7hZl1/9I8yzKLx3aR9Xbof3fBHKunvMfOCYAtMhrsnccJY2iTURb9EZd5+pLuiNV9/c/GZJOHsgIw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update npm packages Note that the Prettier update made it possible to move a couple of comments after `default:`-cases back to their original/intended positions, please see https://prettier.io/blog/2022/03/16/2.6.0.html
2022-03-20 10:36:11 +01:00
"funding": [
{
"type": "opencollective",
"url": "https://opencollective.com/postcss/"
},
{
"type": "tidelift",
"url": "https://tidelift.com/funding/github/npm/postcss"
Update packages to the most recent versions
2023-04-23 13:48:22 +02:00
},
{
"type": "github",
"url": "https://github.com/sponsors/ai"
Update npm packages Note that the Prettier update made it possible to move a couple of comments after `default:`-cases back to their original/intended positions, please see https://prettier.io/blog/2022/03/16/2.6.0.html
2022-03-20 10:36:11 +01:00
}
],
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update npm packages
2023-12-23 12:29:51 +01:00
"nanoid": "^3.3.7",
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"picocolors": "^1.0.1",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"source-map-js": "^1.2.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": "^10 || ^12 || >=14"
}
},
Restore the option to set light/dark mode for chromium and generic builds
2023-11-18 18:18:36 +01:00
"node_modules/postcss-dark-theme-class": {
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"version": "1.3.0",
"resolved": "https://registry.npmjs.org/postcss-dark-theme-class/-/postcss-dark-theme-class-1.3.0.tgz",
"integrity": "sha512-prap+7LDzkWUzf8yciQsZdPi+Fm0k699KBCubLu6n9P5HCTyKCpxRJILPhs/L9m5JLTA/7xrICApse+nk5Qkmw==",
Restore the option to set light/dark mode for chromium and generic builds
2023-11-18 18:18:36 +01:00
"dev": true,
"funding": [
{
"type": "opencollective",
"url": "https://opencollective.com/postcss/"
},
{
"type": "github",
"url": "https://github.com/sponsors/ai"
}
],
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"dependencies": {
"postcss-value-parser": "^4.2.0"
},
Restore the option to set light/dark mode for chromium and generic builds
2023-11-18 18:18:36 +01:00
"engines": {
"node": ">=18.0"
},
"peerDependencies": {
"postcss": "^8.2.14"
}
},
Replace `dir`-dependent `margin`/`margin-left`/`margin-right` with logical properties *Please note:* This is another step in what will, time permitting, become a series of patches to simplify/modernize the viewer CSS. Rather than having to manually specify ltr/rtl-specific margin-values in the CSS, we can use logical margin instead (and similar for some related left/right occurrences). These logical properties depend on, among other things, the direction of the HTML document which we *always* specify in the viewer. Given that most of these logical CSS properties are fairly new, and that cross-browser support is thus somewhat limited (see below), we need to use a couple of PostCSS plugins (see below) in order to support this in the GENERIC viewer. - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-end#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-end#browser_compatibility --- - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-logical - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-dir-pseudo-class
2022-03-13 18:30:51 +01:00
"node_modules/postcss-dir-pseudo-class": {
Update npm packages
2023-12-23 12:29:51 +01:00
"version": "8.0.1",
"resolved": "https://registry.npmjs.org/postcss-dir-pseudo-class/-/postcss-dir-pseudo-class-8.0.1.tgz",
"integrity": "sha512-uULohfWBBVoFiZXgsQA24JV6FdKIidQ+ZqxOouhWwdE+qJlALbkS5ScB43ZTjPK+xUZZhlaO/NjfCt5h4IKUfw==",
Replace `dir`-dependent `margin`/`margin-left`/`margin-right` with logical properties *Please note:* This is another step in what will, time permitting, become a series of patches to simplify/modernize the viewer CSS. Rather than having to manually specify ltr/rtl-specific margin-values in the CSS, we can use logical margin instead (and similar for some related left/right occurrences). These logical properties depend on, among other things, the direction of the HTML document which we *always* specify in the viewer. Given that most of these logical CSS properties are fairly new, and that cross-browser support is thus somewhat limited (see below), we need to use a couple of PostCSS plugins (see below) in order to support this in the GENERIC viewer. - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-end#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-end#browser_compatibility --- - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-logical - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-dir-pseudo-class
2022-03-13 18:30:51 +01:00
"dev": true,
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/csstools"
},
{
"type": "opencollective",
"url": "https://opencollective.com/csstools"
}
],
Replace `dir`-dependent `margin`/`margin-left`/`margin-right` with logical properties *Please note:* This is another step in what will, time permitting, become a series of patches to simplify/modernize the viewer CSS. Rather than having to manually specify ltr/rtl-specific margin-values in the CSS, we can use logical margin instead (and similar for some related left/right occurrences). These logical properties depend on, among other things, the direction of the HTML document which we *always* specify in the viewer. Given that most of these logical CSS properties are fairly new, and that cross-browser support is thus somewhat limited (see below), we need to use a couple of PostCSS plugins (see below) in order to support this in the GENERIC viewer. - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-end#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-end#browser_compatibility --- - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-logical - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-dir-pseudo-class
2022-03-13 18:30:51 +01:00
"dependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"postcss-selector-parser": "^6.0.13"
Replace `dir`-dependent `margin`/`margin-left`/`margin-right` with logical properties *Please note:* This is another step in what will, time permitting, become a series of patches to simplify/modernize the viewer CSS. Rather than having to manually specify ltr/rtl-specific margin-values in the CSS, we can use logical margin instead (and similar for some related left/right occurrences). These logical properties depend on, among other things, the direction of the HTML document which we *always* specify in the viewer. Given that most of these logical CSS properties are fairly new, and that cross-browser support is thus somewhat limited (see below), we need to use a couple of PostCSS plugins (see below) in order to support this in the GENERIC viewer. - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-end#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-end#browser_compatibility --- - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-logical - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-dir-pseudo-class
2022-03-13 18:30:51 +01:00
},
"engines": {
Update npm packages
2023-01-28 08:13:13 +01:00
"node": "^14 || ^16 || >=18"
Replace `dir`-dependent `margin`/`margin-left`/`margin-right` with logical properties *Please note:* This is another step in what will, time permitting, become a series of patches to simplify/modernize the viewer CSS. Rather than having to manually specify ltr/rtl-specific margin-values in the CSS, we can use logical margin instead (and similar for some related left/right occurrences). These logical properties depend on, among other things, the direction of the HTML document which we *always* specify in the viewer. Given that most of these logical CSS properties are fairly new, and that cross-browser support is thus somewhat limited (see below), we need to use a couple of PostCSS plugins (see below) in order to support this in the GENERIC viewer. - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-end#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-end#browser_compatibility --- - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-logical - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-dir-pseudo-class
2022-03-13 18:30:51 +01:00
},
"peerDependencies": {
Update npm packages
2023-01-28 08:13:13 +01:00
"postcss": "^8.4"
Replace `dir`-dependent `margin`/`margin-left`/`margin-right` with logical properties *Please note:* This is another step in what will, time permitting, become a series of patches to simplify/modernize the viewer CSS. Rather than having to manually specify ltr/rtl-specific margin-values in the CSS, we can use logical margin instead (and similar for some related left/right occurrences). These logical properties depend on, among other things, the direction of the HTML document which we *always* specify in the viewer. Given that most of these logical CSS properties are fairly new, and that cross-browser support is thus somewhat limited (see below), we need to use a couple of PostCSS plugins (see below) in order to support this in the GENERIC viewer. - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-end#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-start#browser_compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/inset-inline-end#browser_compatibility --- - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-logical - https://github.com/csstools/postcss-plugins/tree/main/plugins/postcss-dir-pseudo-class
2022-03-13 18:30:51 +01:00
}
},
Remove comments from the *built* CSS files The old pre-processor used for CSS, and HTML, files leaves comments intact which unnecessarily contributes to the overall size of the *built* CSS files (note that the built JavaScript files don't include comments). Rather than trying to "hack" comment removal into the pre-processor it seems easier to use a PostCSS plugin instead. The one potential issue is that it also affects *some* whitespaces, and it's not clear to me if this'll work with the various CSS-related tests that run in mozilla-central. Please refer to https://www.npmjs.com/package/postcss-discard-comments for additional information.
2023-09-22 18:27:08 +02:00
"node_modules/postcss-discard-comments": {
Update dependencies to the most recent versions
2024-06-21 17:09:21 +02:00
"version": "7.0.1",
"resolved": "https://registry.npmjs.org/postcss-discard-comments/-/postcss-discard-comments-7.0.1.tgz",
"integrity": "sha512-GVrQxUOhmle1W6jX2SvNLt4kmN+JYhV7mzI6BMnkAWR9DtVvg8e67rrV0NfdWhn7x1zxvzdWkMBPdBDCls+uwQ==",
Remove comments from the *built* CSS files The old pre-processor used for CSS, and HTML, files leaves comments intact which unnecessarily contributes to the overall size of the *built* CSS files (note that the built JavaScript files don't include comments). Rather than trying to "hack" comment removal into the pre-processor it seems easier to use a PostCSS plugin instead. The one potential issue is that it also affects *some* whitespaces, and it's not clear to me if this'll work with the various CSS-related tests that run in mozilla-central. Please refer to https://www.npmjs.com/package/postcss-discard-comments for additional information.
2023-09-22 18:27:08 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-06-21 17:09:21 +02:00
"license": "MIT",
"dependencies": {
"postcss-selector-parser": "^6.1.0"
},
Remove comments from the *built* CSS files The old pre-processor used for CSS, and HTML, files leaves comments intact which unnecessarily contributes to the overall size of the *built* CSS files (note that the built JavaScript files don't include comments). Rather than trying to "hack" comment removal into the pre-processor it seems easier to use a PostCSS plugin instead. The one potential issue is that it also affects *some* whitespaces, and it's not clear to me if this'll work with the various CSS-related tests that run in mozilla-central. Please refer to https://www.npmjs.com/package/postcss-discard-comments for additional information.
2023-09-22 18:27:08 +02:00
"engines": {
Upgrade `postcss-discard-comments` to version 7.0.0 This is a major version bump, but the changelog at https://github.com/cssnano/cssnano/releases/tag/cssnano%407.0.0 doesn't indicate any breaking changes that should impact us.
2024-04-29 19:55:38 +02:00
"node": "^18.12.0 || ^20.9.0 || >=22.0"
Remove comments from the *built* CSS files The old pre-processor used for CSS, and HTML, files leaves comments intact which unnecessarily contributes to the overall size of the *built* CSS files (note that the built JavaScript files don't include comments). Rather than trying to "hack" comment removal into the pre-processor it seems easier to use a PostCSS plugin instead. The one potential issue is that it also affects *some* whitespaces, and it's not clear to me if this'll work with the various CSS-related tests that run in mozilla-central. Please refer to https://www.npmjs.com/package/postcss-discard-comments for additional information.
2023-09-22 18:27:08 +02:00
},
"peerDependencies": {
Update npm packages
2023-12-23 12:29:51 +01:00
"postcss": "^8.4.31"
Remove comments from the *built* CSS files The old pre-processor used for CSS, and HTML, files leaves comments intact which unnecessarily contributes to the overall size of the *built* CSS files (note that the built JavaScript files don't include comments). Rather than trying to "hack" comment removal into the pre-processor it seems easier to use a PostCSS plugin instead. The one potential issue is that it also affects *some* whitespaces, and it's not clear to me if this'll work with the various CSS-related tests that run in mozilla-central. Please refer to https://www.npmjs.com/package/postcss-discard-comments for additional information.
2023-09-22 18:27:08 +02:00
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/postcss-load-config": {
Update npm packages
2024-01-20 09:40:33 +01:00
"version": "5.0.2",
"resolved": "https://registry.npmjs.org/postcss-load-config/-/postcss-load-config-5.0.2.tgz",
"integrity": "sha512-Q8QR3FYbqOKa0bnC1UQ2bFq9/ulHX5Bi34muzitMr8aDtUelO5xKeJEYC/5smE0jNE9zdB/NBnOwXKexELbRlw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update npm packages
2024-01-20 09:40:33 +01:00
"funding": [
{
"type": "opencollective",
"url": "https://opencollective.com/postcss/"
},
{
"type": "github",
"url": "https://github.com/sponsors/ai"
}
],
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update npm packages
2024-01-20 09:40:33 +01:00
"lilconfig": "^3.0.0",
"yaml": "^2.3.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update npm packages
2024-01-20 09:40:33 +01:00
"node": ">= 18"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependencies": {
Update npm packages
2024-01-20 09:40:33 +01:00
"jiti": ">=1.21.0",
"postcss": ">=8.0.9"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependenciesMeta": {
Update npm packages
2024-01-20 09:40:33 +01:00
"jiti": {
"optional": true
},
"postcss": {
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"optional": true
}
}
},
[Editor] Fix the resizing of an editor when it's rotated (bug 1847268) There are 2 rotation we've to deal with: the viewer one and the editor one. The previous implementation was a bit complex and having to deal with these rotation would have potentially increase it. So this patch aims to simplify the implementation and deal with all the possible cases. The main idea is to transform the mouse deltas according to the rotations and then apply the resizing in the page coordinates system.
2023-08-04 18:21:27 +02:00
"node_modules/postcss-nesting": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"version": "12.1.5",
"resolved": "https://registry.npmjs.org/postcss-nesting/-/postcss-nesting-12.1.5.tgz",
"integrity": "sha512-N1NgI1PDCiAGWPTYrwqm8wpjv0bgDmkYHH72pNsqTCv9CObxjxftdYu6AKtGN+pnJa7FQjMm3v4sp8QJbFsYdQ==",
[Editor] Fix the resizing of an editor when it's rotated (bug 1847268) There are 2 rotation we've to deal with: the viewer one and the editor one. The previous implementation was a bit complex and having to deal with these rotation would have potentially increase it. So this patch aims to simplify the implementation and deal with all the possible cases. The main idea is to transform the mouse deltas according to the rotations and then apply the resizing in the page coordinates system.
2023-08-04 18:21:27 +02:00
"dev": true,
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/csstools"
},
{
"type": "opencollective",
"url": "https://opencollective.com/csstools"
}
],
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT-0",
[Editor] Fix the resizing of an editor when it's rotated (bug 1847268) There are 2 rotation we've to deal with: the viewer one and the editor one. The previous implementation was a bit complex and having to deal with these rotation would have potentially increase it. So this patch aims to simplify the implementation and deal with all the possible cases. The main idea is to transform the mouse deltas according to the rotations and then apply the resizing in the page coordinates system.
2023-08-04 18:21:27 +02:00
"dependencies": {
Update npm packages
2024-03-17 13:50:21 +01:00
"@csstools/selector-resolve-nested": "^1.1.0",
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"@csstools/selector-specificity": "^3.1.1",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"postcss-selector-parser": "^6.1.0"
[Editor] Fix the resizing of an editor when it's rotated (bug 1847268) There are 2 rotation we've to deal with: the viewer one and the editor one. The previous implementation was a bit complex and having to deal with these rotation would have potentially increase it. So this patch aims to simplify the implementation and deal with all the possible cases. The main idea is to transform the mouse deltas according to the rotations and then apply the resizing in the page coordinates system.
2023-08-04 18:21:27 +02:00
},
"engines": {
"node": "^14 || ^16 || >=18"
},
"peerDependencies": {
"postcss": "^8.4"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/postcss-resolve-nested-selector": {
"version": "0.1.1",
"resolved": "https://registry.npmjs.org/postcss-resolve-nested-selector/-/postcss-resolve-nested-selector-0.1.1.tgz",
"integrity": "sha1-Kcy8fDfe36wwTp//C/FZaz9qDk4=",
"dev": true
},
"node_modules/postcss-safe-parser": {
Update npm packages
2023-12-23 12:29:51 +01:00
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/postcss-safe-parser/-/postcss-safe-parser-7.0.0.tgz",
"integrity": "sha512-ovehqRNVCpuFzbXoTb4qLtyzK3xn3t/CUBxOs8LsnQjQrShaB4lKiHoVqY8ANaC0hBMHq5QVWk77rwGklFUDrg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update npm packages
2023-12-23 12:29:51 +01:00
"funding": [
{
"type": "opencollective",
"url": "https://opencollective.com/postcss/"
},
{
"type": "tidelift",
"url": "https://tidelift.com/funding/github/npm/postcss-safe-parser"
},
{
"type": "github",
"url": "https://github.com/sponsors/ai"
}
],
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Update npm packages
2023-12-23 12:29:51 +01:00
"node": ">=18.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependencies": {
Update npm packages
2023-12-23 12:29:51 +01:00
"postcss": "^8.4.31"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/postcss-selector-parser": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"version": "6.1.0",
"resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-6.1.0.tgz",
"integrity": "sha512-UMz42UD0UY0EApS0ZL9o1XnLhSTtvvvLe5Dc2H2O56fvRZi+KulDyf5ctDhhtYJBGKStV2FL1fy6253cmLgqVQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"cssesc": "^3.0.0",
"util-deprecate": "^1.0.2"
},
"engines": {
"node": ">=4"
}
},
"node_modules/postcss-value-parser": {
Update npm packages
2022-01-09 10:05:52 +01:00
"version": "4.2.0",
"resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-4.2.0.tgz",
"integrity": "sha512-1NNCs6uurfkVbeXG4S8JFT9t19m45ICnif8zWLd5oPSZ50QnwMfK+H3jv408d4jw/7Bttv5axS5IiHoLaVNHeQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/prebuild-install": {
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/prebuild-install/-/prebuild-install-7.1.1.tgz",
"integrity": "sha512-jAXscXWMcCK8GgCoHOfIr0ODh5ai8mj63L2nWrjuAgXE6tDyYGnx4/8o/rCgU+B4JSyZBKbeZqzhtwtC3ovxjw==",
"dev": true,
"dependencies": {
"detect-libc": "^2.0.0",
"expand-template": "^2.0.3",
"github-from-package": "0.0.0",
"minimist": "^1.2.3",
"mkdirp-classic": "^0.5.3",
"napi-build-utils": "^1.0.1",
"node-abi": "^3.3.0",
"pump": "^3.0.0",
"rc": "^1.2.7",
"simple-get": "^4.0.0",
"tar-fs": "^2.0.0",
"tunnel-agent": "^0.6.0"
},
"bin": {
"prebuild-install": "bin.js"
},
"engines": {
"node": ">=10"
}
},
"node_modules/prebuild-install/node_modules/decompress-response": {
"version": "6.0.0",
"resolved": "https://registry.npmjs.org/decompress-response/-/decompress-response-6.0.0.tgz",
"integrity": "sha512-aW35yZM6Bb/4oJlZncMH2LCoZtJXTRxES17vE3hoRiowU2kWHaJKFkSBDnDR+cm9J+9QhXmREyIfv0pji9ejCQ==",
"dev": true,
"dependencies": {
"mimic-response": "^3.1.0"
},
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/prebuild-install/node_modules/detect-libc": {
"version": "2.0.2",
"resolved": "https://registry.npmjs.org/detect-libc/-/detect-libc-2.0.2.tgz",
"integrity": "sha512-UX6sGumvvqSaXgdKGUsgZWqcUyIXZ/vZTrlRT/iobiKhGL0zL4d3osHj3uqllWJK+i+sixDS/3COVEOFbupFyw==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/prebuild-install/node_modules/mimic-response": {
"version": "3.1.0",
"resolved": "https://registry.npmjs.org/mimic-response/-/mimic-response-3.1.0.tgz",
"integrity": "sha512-z0yWI+4FDrrweS8Zmt4Ej5HdJmky15+L2e6Wgn3+iK5fWzb6T3fhNFq2+MeTRb064c6Wr4N/wv0DzQTjNzHNGQ==",
"dev": true,
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/prebuild-install/node_modules/readable-stream": {
"version": "3.6.2",
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.2.tgz",
"integrity": "sha512-9u/sniCrY3D5WdsERHzHE4G2YCXqoG5FTHUiCC4SIbr6XcLZBY05ya9EKjYek9O5xOAwjGq+1JdGBAS7Q9ScoA==",
"dev": true,
"dependencies": {
"inherits": "^2.0.3",
"string_decoder": "^1.1.1",
"util-deprecate": "^1.0.1"
},
"engines": {
"node": ">= 6"
}
},
"node_modules/prebuild-install/node_modules/simple-get": {
"version": "4.0.1",
"resolved": "https://registry.npmjs.org/simple-get/-/simple-get-4.0.1.tgz",
"integrity": "sha512-brv7p5WgH0jmQJr1ZDDfKDOSeWWg+OVypG99A/5vYGPqJ6pxiaHLy8nxtFjBA7oMa01ebA9gfh1uMCFqOuXxvA==",
"dev": true,
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/feross"
},
{
"type": "patreon",
"url": "https://www.patreon.com/feross"
},
{
"type": "consulting",
"url": "https://feross.org/support"
}
],
"dependencies": {
"decompress-response": "^6.0.0",
"once": "^1.3.1",
"simple-concat": "^1.0.0"
}
},
"node_modules/prebuild-install/node_modules/tar-fs": {
"version": "2.1.1",
"resolved": "https://registry.npmjs.org/tar-fs/-/tar-fs-2.1.1.tgz",
"integrity": "sha512-V0r2Y9scmbDRLCNex/+hYzvp/zyYjvFbHPNgVTKfQvVrb6guiE/fxP+XblDNR011utopbkex2nM4dHNV6GDsng==",
"dev": true,
"dependencies": {
"chownr": "^1.1.1",
"mkdirp-classic": "^0.5.2",
"pump": "^3.0.0",
"tar-stream": "^2.1.4"
}
},
"node_modules/prebuild-install/node_modules/tar-stream": {
"version": "2.2.0",
"resolved": "https://registry.npmjs.org/tar-stream/-/tar-stream-2.2.0.tgz",
"integrity": "sha512-ujeqbceABgwMZxEJnk2HDY2DlnUZ+9oEcb1KzTVfYHio0UE6dG71n60d8D2I4qNvleWrrXpmjpt7vZeF1LnMZQ==",
"dev": true,
"dependencies": {
"bl": "^4.0.3",
"end-of-stream": "^1.4.1",
"fs-constants": "^1.0.0",
"inherits": "^2.0.3",
"readable-stream": "^3.1.1"
},
"engines": {
"node": ">=6"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/prettier": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "3.3.3",
"resolved": "https://registry.npmjs.org/prettier/-/prettier-3.3.3.tgz",
"integrity": "sha512-i2tDNA0O5IrMO757lfrdQZCc2jPNDVntV0m/+4whiDfWaTKfMNgR7Qz0NAeGz/nRqF4m5/6CLzbP4/liHt12Ew==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"bin": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"prettier": "bin/prettier.cjs"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node": ">=14"
Update npm packages Note that the Prettier update made it possible to move a couple of comments after `default:`-cases back to their original/intended positions, please see https://prettier.io/blog/2022/03/16/2.6.0.html
2022-03-20 10:36:11 +01:00
},
"funding": {
"url": "https://github.com/prettier/prettier?sponsor=1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/prettier-linter-helpers": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/prettier-linter-helpers/-/prettier-linter-helpers-1.0.0.tgz",
"integrity": "sha512-GbK2cP9nraSSUF9N2XwUwqfzlAFlMNYYl+ShE/V+H8a9uNl/oUqB1w2EL54Jh0OlyRSd8RfWYJ3coVS4TROP2w==",
"dev": true,
"dependencies": {
"fast-diff": "^1.1.2"
},
"engines": {
"node": ">=6.0.0"
}
},
"node_modules/process-nextick-args": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/process-nextick-args/-/process-nextick-args-2.0.0.tgz",
"integrity": "sha512-MtEC1TqN0EU5nephaJ4rAtThHtC86dNN9qCuEhtshvpVBkAW5ZO7BASN9REnF9eoXGcRub+pFuKEpOHE+HbEMw==",
"dev": true
},
"node_modules/progress": {
"version": "2.0.3",
"resolved": "https://registry.npmjs.org/progress/-/progress-2.0.3.tgz",
"integrity": "sha512-7PiHtLll5LdnKIMw100I+8xJXR5gW2QwWYkT6iJva0bXitZKa/XMrSbdmg3r2Xnaidz9Qumd0VPaMrZlF9V9sA==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=0.4.0"
}
},
"node_modules/promise": {
"version": "7.3.1",
"resolved": "https://registry.npmjs.org/promise/-/promise-7.3.1.tgz",
"integrity": "sha512-nolQXZ/4L+bP/UGlkfaIujX9BKxGwmQ9OT4mOt5yvy8iK1h3wqTEJCijzGANTCCl9nWjY41juyAn2K3Q1hLLTg==",
"dev": true,
"dependencies": {
"asap": "~2.0.3"
}
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/prop-types": {
"version": "15.8.1",
"resolved": "https://registry.npmjs.org/prop-types/-/prop-types-15.8.1.tgz",
"integrity": "sha512-oj87CgZICdulUohogVAR7AjlC0327U4el4L6eAvOqCeudMDVU0NThNaV+b9Df4dXgSP1gXMTnPdhfe/2qDH5cg==",
"dev": true,
"peer": true,
"dependencies": {
"loose-envify": "^1.4.0",
"object-assign": "^4.1.1",
"react-is": "^16.13.1"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/proper-lockfile": {
"version": "4.1.2",
"resolved": "https://registry.npmjs.org/proper-lockfile/-/proper-lockfile-4.1.2.tgz",
"integrity": "sha512-TjNPblN4BwAWMXU8s9AEz4JmQxnD1NNL7bNOY/AKUzyamc379FWASUhc/K1pL2noVb+XmZKLL68cjzLsiOAMaA==",
"dev": true,
"dependencies": {
"graceful-fs": "^4.2.4",
"retry": "^0.12.0",
"signal-exit": "^3.0.2"
}
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/proxy-agent": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"version": "6.4.0",
"resolved": "https://registry.npmjs.org/proxy-agent/-/proxy-agent-6.4.0.tgz",
"integrity": "sha512-u0piLU+nCOHMgGjRbimiXmA9kM/L9EHh3zL81xCdp7m+Y2pHIsnmbdDoEDoAz5geaonNR6q6+yOPQs6n4T6sBQ==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"agent-base": "^7.0.2",
"debug": "^4.3.4",
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"http-proxy-agent": "^7.0.1",
"https-proxy-agent": "^7.0.3",
Update npm packages
2023-07-23 09:49:53 +02:00
"lru-cache": "^7.14.1",
Update Puppeteer to version 21.2.1 This release fixes the upstream bug that caused old Firefox revisions to not be removed from the cache. Fixes #16904.
2023-09-16 14:02:41 +02:00
"pac-proxy-agent": "^7.0.1",
Update npm packages
2023-07-23 09:49:53 +02:00
"proxy-from-env": "^1.1.0",
Update Puppeteer to version 21.2.1 This release fixes the upstream bug that caused old Firefox revisions to not be removed from the cache. Fixes #16904.
2023-09-16 14:02:41 +02:00
"socks-proxy-agent": "^8.0.2"
Update npm packages
2023-07-23 09:49:53 +02:00
},
"engines": {
"node": ">= 14"
}
},
"node_modules/proxy-agent/node_modules/agent-base": {
Update dependencies to the most recent versions
2024-04-03 14:42:19 +02:00
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/agent-base/-/agent-base-7.1.1.tgz",
"integrity": "sha512-H0TSyFNDMomMNJQBn8wFV5YC/2eJ+VXECwOadZJT554xP6cODZHPX3H9QMQECxvrgiSOP1pHjy1sMWQVYJOUOA==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"debug": "^4.3.4"
},
"engines": {
"node": ">= 14"
}
},
"node_modules/proxy-agent/node_modules/https-proxy-agent": {
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"version": "7.0.5",
"resolved": "https://registry.npmjs.org/https-proxy-agent/-/https-proxy-agent-7.0.5.tgz",
"integrity": "sha512-1e4Wqeblerz+tMKPIq2EMGiiWW1dIjZOksyHWSUm1rmuvw/how9hBHZ38lAGj5ID4Ik6EdkOw7NmWPy6LAwalw==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2023-07-23 09:49:53 +02:00
"dependencies": {
"agent-base": "^7.0.2",
"debug": "4"
},
"engines": {
"node": ">= 14"
}
},
"node_modules/proxy-agent/node_modules/lru-cache": {
"version": "7.18.3",
"resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-7.18.3.tgz",
"integrity": "sha512-jumlc0BIUrS3qJGgIkWZsyfAM7NCWiBcCDhnd+3NNM5KbBmLTgHVfWBcg6W+rLUsIpzpERPsvwUP7CckAQSOoA==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "ISC",
Update npm packages
2023-07-23 09:49:53 +02:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">=12"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/proxy-from-env": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/proxy-from-env/-/proxy-from-env-1.1.0.tgz",
"integrity": "sha512-D+zkORCbA9f1tdWRK0RaCR3GPv50cMxcrz4X8k5LTSUD1Dkw47mKJEZQNunItRTkWwgtaUSo1RVFRIG9ZXiFYg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/prr": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/prr/-/prr-1.0.1.tgz",
"integrity": "sha1-0/wRS6BplaRexok/SEzrHXj19HY=",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"node_modules/pump": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/pump/-/pump-3.0.0.tgz",
"integrity": "sha512-LwZy+p3SFs1Pytd/jYct4wpv49HiYCqd9Rlc5ZVdk0V+8Yzv6jR5Blk3TRmPL1ft69TxP0IMZGJ+WPFU2BFhww==",
"dev": true,
"license": "MIT",
"dependencies": {
"end-of-stream": "^1.1.0",
"once": "^1.3.1"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/punycode": {
"version": "2.1.1",
"resolved": "https://registry.npmjs.org/punycode/-/punycode-2.1.1.tgz",
"integrity": "sha512-XRsRjdf+j5ml+y/6GKHPZbrF/8p2Yga0JPtdqTIY2Xe5ohJPD9saDJJLPvp9+NSBprVvevdXZybnj2cv8OEd0A==",
"dev": true,
"engines": {
"node": ">=6"
}
},
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"node_modules/punycode.js": {
"version": "2.3.1",
"resolved": "https://registry.npmjs.org/punycode.js/-/punycode.js-2.3.1.tgz",
"integrity": "sha512-uxFIHU0YlHYhDQtV4R9J6a52SLx28BCjT+4ieh7IGbgwVJWO+km431c4yRlREUAsAmt/uMjQUyQHNEPf0M39CA==",
"dev": true,
"engines": {
"node": ">=6"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/puppeteer": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "22.13.0",
"resolved": "https://registry.npmjs.org/puppeteer/-/puppeteer-22.13.0.tgz",
"integrity": "sha512-nmICzeHTBtZiu+y4vs0fboe/NKIFwH5W8RZuxmEVAKNfBQg/8u5FEQAvPlWmyVpJoAVM5kXD5PEl3GlK3F9pPA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"hasInstallScript": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "Apache-2.0",
Update npm packages
2022-10-16 09:09:38 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"@puppeteer/browsers": "2.2.3",
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"cosmiconfig": "^9.0.0",
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"devtools-protocol": "0.0.1299070",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"puppeteer-core": "22.13.0"
Update Puppeteer to version 21.6.0 and force "CDP" protocol
2023-12-08 12:27:44 +01:00
},
"bin": {
"puppeteer": "lib/esm/puppeteer/node/cli.js"
Update npm packages
2023-06-25 09:18:41 +02:00
},
"engines": {
Update `puppeteer` to version 22.0.0 This is a major version bump that requires two changes on our side: - The new headless mode is now the default, so we can remove our transformation code (see https://github.com/puppeteer/puppeteer/pull/11815). - The `page.waitForTimeout` API is removed. Sadly we still used it in the integration tests (but fortunately much less than before we worked on fixing intermittent failures), so until we remove the final occurrences we provide an implementation ourselves (see https://github.com/puppeteer/puppeteer/pull/11780). The full changelog can be found here: https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.0.0
2024-02-10 18:21:34 +01:00
"node": ">=18"
Update npm packages
2022-10-16 09:09:38 +02:00
}
},
"node_modules/puppeteer-core": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "22.13.0",
"resolved": "https://registry.npmjs.org/puppeteer-core/-/puppeteer-core-22.13.0.tgz",
"integrity": "sha512-ZkpRX8nm/S39BnpcCverMzIc6oGWBPOUeOeaWRLKHqiKVCZ1l28HxPTYLitJlDiB16xZATSKpjul+sl+ZEm0HQ==",
Update npm packages
2022-10-16 09:09:38 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "Apache-2.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"@puppeteer/browsers": "2.2.3",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"chromium-bidi": "0.6.0",
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"debug": "^4.3.5",
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"devtools-protocol": "0.0.1299070",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"ws": "^8.18.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update `puppeteer` to version 22.0.0 This is a major version bump that requires two changes on our side: - The new headless mode is now the default, so we can remove our transformation code (see https://github.com/puppeteer/puppeteer/pull/11815). - The `page.waitForTimeout` API is removed. Sadly we still used it in the integration tests (but fortunately much less than before we worked on fixing intermittent failures), so until we remove the final occurrences we provide an implementation ourselves (see https://github.com/puppeteer/puppeteer/pull/11780). The full changelog can be found here: https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.0.0
2024-02-10 18:21:34 +01:00
"node": ">=18"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update npm packages
2022-10-16 09:09:38 +02:00
"node_modules/puppeteer-core/node_modules/debug": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "4.3.5",
"resolved": "https://registry.npmjs.org/debug/-/debug-4.3.5.tgz",
"integrity": "sha512-pt0bNEmneDIvdL1Xsd9oDQ/wrQRkXDT4AUWlNZNPKvW5x/jyO9VFXkJUP07vQ2upmw5PlaITaPKc31jK13V+jg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"ms": "2.1.2"
},
"engines": {
"node": ">=6.0"
},
"peerDependenciesMeta": {
"supports-color": {
"optional": true
}
}
},
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"node_modules/queue-lit": {
"version": "1.5.0",
"resolved": "https://registry.npmjs.org/queue-lit/-/queue-lit-1.5.0.tgz",
"integrity": "sha512-IslToJ4eiCEE9xwMzq3viOO5nH8sUWUCwoElrhNMozzr9IIt2qqvB4I+uHu/zJTQVqc9R5DFwok4ijNK1pU3fA==",
"dev": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/queue-microtask": {
"version": "1.2.3",
"resolved": "https://registry.npmjs.org/queue-microtask/-/queue-microtask-1.2.3.tgz",
"integrity": "sha512-NuaNSa6flKT5JaSYQzJok04JzTL1CA6aGhv5rfLW3PgqA+M2ChpZQnAC8h8i4ZFkBS8X5RqkDBHA7r4hej3K9A==",
"dev": true,
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/feross"
},
{
"type": "patreon",
"url": "https://www.patreon.com/feross"
},
{
"type": "consulting",
"url": "https://feross.org/support"
}
]
},
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"node_modules/queue-tick": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/queue-tick/-/queue-tick-1.0.1.tgz",
"integrity": "sha512-kJt5qhMxoszgU/62PLP1CJytzd2NKetjSRnyuj31fDd3Rlcz3fzlFdFLD1SItunPwyqEOkca6GbV612BWfaBag==",
"dev": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/randombytes": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/randombytes/-/randombytes-2.1.0.tgz",
"integrity": "sha512-vYl3iOX+4CKUWuxGi9Ukhie6fsqXqS9FE2Zaic4tNFD2N2QQaXOMFbuKK4QmDHC0JO6B1Zp41J0LpT0oR68amQ==",
"dev": true,
"dependencies": {
"safe-buffer": "^5.1.0"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/rc": {
"version": "1.2.8",
"resolved": "https://registry.npmjs.org/rc/-/rc-1.2.8.tgz",
"integrity": "sha512-y3bGgqKj3QBdxLbLkomlohkvsA8gdAiUQlSBJnBhfn+BPxg4bc62d8TcBW15wavDfgexCgccckhcZvywyQYPOw==",
"dev": true,
"dependencies": {
"deep-extend": "^0.6.0",
"ini": "~1.3.0",
"minimist": "^1.2.0",
"strip-json-comments": "~2.0.1"
},
"bin": {
"rc": "cli.js"
}
},
"node_modules/rc/node_modules/strip-json-comments": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-2.0.1.tgz",
"integrity": "sha512-4gB8na07fecVVkOI6Rs4e7T6NOTki5EmL7TUduTs6bu3EdnSycntVJ4re8kgZA+wx9IueI2Y11bfbgwtzuE0KQ==",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/react-is": {
"version": "16.13.1",
"resolved": "https://registry.npmjs.org/react-is/-/react-is-16.13.1.tgz",
"integrity": "sha512-24e6ynE2H+OKt4kqsOvNd8kBpV65zoxbA4BVsEOB3ARVWQki/DHzaUoC5KuON/BiccDaCCTZBuOcfZs70kR8bQ==",
"dev": true,
"peer": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/read-pkg": {
"version": "5.2.0",
"resolved": "https://registry.npmjs.org/read-pkg/-/read-pkg-5.2.0.tgz",
"integrity": "sha512-Ug69mNOpfvKDAc2Q8DRpMjjzdtrnv9HcSMX+4VsZxD1aZ6ZzrIE7rlzXBtWTyhULSMKg076AW6WR5iZpD0JiOg==",
"dev": true,
"dependencies": {
"@types/normalize-package-data": "^2.4.0",
"normalize-package-data": "^2.5.0",
"parse-json": "^5.0.0",
"type-fest": "^0.6.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/read-pkg-up": {
"version": "7.0.1",
"resolved": "https://registry.npmjs.org/read-pkg-up/-/read-pkg-up-7.0.1.tgz",
"integrity": "sha512-zK0TB7Xd6JpCLmlLmufqykGE+/TlOePD6qKClNW7hHDKFh/J7/7gCWGR7joEQEW1bKq3a3yUZSObOoWLFQ4ohg==",
"dev": true,
"dependencies": {
"find-up": "^4.1.0",
"read-pkg": "^5.2.0",
"type-fest": "^0.8.1"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/read-pkg-up/node_modules/find-up": {
"version": "4.1.0",
"resolved": "https://registry.npmjs.org/find-up/-/find-up-4.1.0.tgz",
"integrity": "sha512-PpOwAdQ/YlXQ2vj8a3h8IipDuYRi3wceVQQGYWxNINccq40Anw7BlsEXCMbt1Zt+OLA6Fq9suIpIWD0OsnISlw==",
"dev": true,
"dependencies": {
"locate-path": "^5.0.0",
"path-exists": "^4.0.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/read-pkg-up/node_modules/locate-path": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/locate-path/-/locate-path-5.0.0.tgz",
"integrity": "sha512-t7hw9pI+WvuwNJXwk5zVHpyhIqzg2qTlklJOf0mVxGSbe3Fp2VieZcduNYjaLDoy6p9uGpQEGWG87WpMKlNq8g==",
"dev": true,
"dependencies": {
"p-locate": "^4.1.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/read-pkg-up/node_modules/p-limit": {
"version": "2.3.0",
"resolved": "https://registry.npmjs.org/p-limit/-/p-limit-2.3.0.tgz",
"integrity": "sha512-//88mFWSJx8lxCzwdAABTJL2MyWB12+eIY7MDL2SqLmAkeKU9qxRvWuSyTjm3FUmpBEMuFfckAIqEaVGUDxb6w==",
"dev": true,
"dependencies": {
"p-try": "^2.0.0"
},
"engines": {
"node": ">=6"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/read-pkg-up/node_modules/p-locate": {
"version": "4.1.0",
"resolved": "https://registry.npmjs.org/p-locate/-/p-locate-4.1.0.tgz",
"integrity": "sha512-R79ZZ/0wAxKGu3oYMlz8jy/kbhsNrS7SKZ7PxEHBgJ5+F2mtFW2fK2cOtBh1cHYkQsbzFV7I+EoRKe6Yt0oK7A==",
"dev": true,
"dependencies": {
"p-limit": "^2.2.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/read-pkg-up/node_modules/p-try": {
"version": "2.2.0",
"resolved": "https://registry.npmjs.org/p-try/-/p-try-2.2.0.tgz",
"integrity": "sha512-R4nPAVTAU0B9D35/Gk3uJf/7XYbQcyohSKdvAxIRSNghFl4e71hVoGnBNQz9cWaXxO2I10KTC+3jMdvvoKw6dQ==",
"dev": true,
"engines": {
"node": ">=6"
}
},
"node_modules/read-pkg-up/node_modules/path-exists": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/path-exists/-/path-exists-4.0.0.tgz",
"integrity": "sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/read-pkg/node_modules/parse-json": {
"version": "5.2.0",
"resolved": "https://registry.npmjs.org/parse-json/-/parse-json-5.2.0.tgz",
"integrity": "sha512-ayCKvm/phCGxOkYRSCM82iDwct8/EonSEgCSxWxD7ve6jHggsFl4fZVQBPRNgQoKiuV/odhFrGzQXZwbifC8Rg==",
"dev": true,
"dependencies": {
"@babel/code-frame": "^7.0.0",
"error-ex": "^1.3.1",
"json-parse-even-better-errors": "^2.3.0",
"lines-and-columns": "^1.1.6"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/read-pkg/node_modules/type-fest": {
"version": "0.6.0",
"resolved": "https://registry.npmjs.org/type-fest/-/type-fest-0.6.0.tgz",
"integrity": "sha512-q+MB8nYR1KDLrgr4G5yemftpMC7/QLqVndBmEEdqzmNj5dcFOO4Oo8qlwZE3ULT3+Zim1F8Kq4cBnikNhlCMlg==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/readable-stream": {
"version": "2.3.6",
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-2.3.6.tgz",
"integrity": "sha512-tQtKA9WIAhBF3+VLAseyMqZeBjW0AHJoxOtYqSUZNJxauErmLbVm2FW1y+J/YA9dUrAC39ITejlZWhVIwawkKw==",
"dev": true,
"dependencies": {
"core-util-is": "~1.0.0",
"inherits": "~2.0.3",
"isarray": "~1.0.0",
"process-nextick-args": "~2.0.0",
"safe-buffer": "~5.1.1",
"string_decoder": "~1.1.1",
"util-deprecate": "~1.0.1"
}
},
"node_modules/rechoir": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "0.8.0",
"resolved": "https://registry.npmjs.org/rechoir/-/rechoir-0.8.0.tgz",
"integrity": "sha512-/vxpCXddiX8NGfGO/mTafwjq4aFa/71pvamip0++IQk3zG8cbCj0fifNPrjjF1XMXUne91jL9OoxmdykoEtifQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"resolve": "^1.20.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/regenerate": {
"version": "1.4.2",
"resolved": "https://registry.npmjs.org/regenerate/-/regenerate-1.4.2.tgz",
"integrity": "sha512-zrceR/XhGYU/d/opr2EKO7aRHUeiBI8qjtfHqADTwZd6Szfy16la6kqD0MIUs5z5hx6AaKa+PixpPrR289+I0A==",
"dev": true
},
Update npm packages
2022-01-09 10:05:52 +01:00
"node_modules/regenerate-unicode-properties": {
Update npm packages
2023-04-15 22:08:58 +02:00
"version": "10.1.0",
"resolved": "https://registry.npmjs.org/regenerate-unicode-properties/-/regenerate-unicode-properties-10.1.0.tgz",
"integrity": "sha512-d1VudCLoIGitcU/hEg2QqvyGZQmdC0Lf8BqdOMXGFSvJP4bNV1+XqbPQeHHLD51Jh4QJJ225dlIFvY4Ly6MXmQ==",
Update npm packages
2022-01-09 10:05:52 +01:00
"dev": true,
"dependencies": {
"regenerate": "^1.4.2"
},
"engines": {
"node": ">=4"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/regenerator-transform": {
Update npm packages
2023-08-19 09:08:11 +02:00
"version": "0.15.2",
"resolved": "https://registry.npmjs.org/regenerator-transform/-/regenerator-transform-0.15.2.tgz",
"integrity": "sha512-hfMp2BoF0qOk3uc5V20ALGDS2ddjQaLrdl7xrGXvAIow7qeWRM2VA2HuCHkUKk9slq3VwEwLNK3DFBqDfPGYtg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"@babel/runtime": "^7.8.4"
}
},
"node_modules/regexp-tree": {
Enable more ESLint `unicorn` plugin rules - `prefer-array-some`, which didn't require any code changes; please find additional details at https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prefer-array-some.md - `prefer-modern-math-apis`, which should be fine given the currently supported browsers; please find additional details at https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prefer-modern-math-apis.md
2023-07-16 09:24:14 +02:00
"version": "0.1.27",
"resolved": "https://registry.npmjs.org/regexp-tree/-/regexp-tree-0.1.27.tgz",
"integrity": "sha512-iETxpjK6YoRWJG5o6hXLwvjYAoW+FEZn9os0PD/b6AP6xQwsa/Y7lCVgIixBbUPMfhu+i2LtdeAqVTgGlQarfA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"bin": {
"regexp-tree": "bin/regexp-tree"
}
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/regexp.prototype.flags": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "1.5.0",
"resolved": "https://registry.npmjs.org/regexp.prototype.flags/-/regexp.prototype.flags-1.5.0.tgz",
"integrity": "sha512-0SutC3pNudRKgquxGoRGIz946MZVHqbNfPjBdxeOhBrdgDKlRoXmYLQN9xRbrR09ZXWeGAdPuif7egofn6v5LA==",
Update npm packages
2022-09-18 10:31:32 +02:00
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
Update npm packages
2023-08-06 09:22:20 +02:00
"define-properties": "^1.2.0",
"functions-have-names": "^1.2.3"
Update npm packages
2022-09-18 10:31:32 +02:00
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/regexpp": {
"version": "3.2.0",
"resolved": "https://registry.npmjs.org/regexpp/-/regexpp-3.2.0.tgz",
"integrity": "sha512-pq2bWo9mVD43nbts2wGv17XLiNLya+GklZ8kaDLV2Z08gDCsGpnKn9BFMepvWuHCbyVvY7J5o5+BVvoQbmlJLg==",
"dev": true,
Update npm packages
2023-03-12 10:27:52 +01:00
"peer": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/mysticatea"
}
},
"node_modules/regexpu-core": {
Update npm packages
2023-04-15 22:08:58 +02:00
"version": "5.3.2",
"resolved": "https://registry.npmjs.org/regexpu-core/-/regexpu-core-5.3.2.tgz",
"integrity": "sha512-RAM5FlZz+Lhmo7db9L298p2vHP5ZywrVXmVXpmAD9GuL5MPH6t9ROw1iA/wfHkQ76Qe7AaPF0nGuim96/IrQMQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2023-04-15 22:08:58 +02:00
"@babel/regjsgen": "^0.8.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"regenerate": "^1.4.2",
Update npm packages
2023-04-15 22:08:58 +02:00
"regenerate-unicode-properties": "^10.1.0",
"regjsparser": "^0.9.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"unicode-match-property-ecmascript": "^2.0.0",
Update npm packages
2023-04-15 22:08:58 +02:00
"unicode-match-property-value-ecmascript": "^2.1.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=4"
}
},
Update npm packages
2022-01-09 10:05:52 +01:00
"node_modules/regjsparser": {
Update npm packages
2023-04-15 22:08:58 +02:00
"version": "0.9.1",
"resolved": "https://registry.npmjs.org/regjsparser/-/regjsparser-0.9.1.tgz",
"integrity": "sha512-dQUtn90WanSNl+7mQKcXAgZxvUe7Z0SqXlgzv0za4LwiUhyzBC58yQO3liFoUgu8GiJVInAhJjkj1N0EtQ5nkQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"jsesc": "~0.5.0"
},
"bin": {
"regjsparser": "bin/parser"
}
},
Update npm packages
2022-01-09 10:05:52 +01:00
"node_modules/regjsparser/node_modules/jsesc": {
"version": "0.5.0",
"resolved": "https://registry.npmjs.org/jsesc/-/jsesc-0.5.0.tgz",
Update npm packages
2022-07-10 10:43:08 +02:00
"integrity": "sha512-uZz5UnB7u4T9LvwmFqXii7pZSouaRPorGs5who1Ip7VO0wxanFvBL7GkM6dTHlgX+jhBApRetaWpnDabOeTcnA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update npm packages
2022-01-09 10:05:52 +01:00
"bin": {
"jsesc": "bin/jsesc"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/remove-trailing-separator": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/remove-trailing-separator/-/remove-trailing-separator-1.1.0.tgz",
"integrity": "sha1-wkvOKig62tW8P1jg1IJJuSN52O8=",
"dev": true
},
"node_modules/replace-ext": {
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/replace-ext/-/replace-ext-2.0.0.tgz",
"integrity": "sha512-UszKE5KVK6JvyD92nzMn9cDapSk6w/CaFZ96CnmDMUqH9oowfxF/ZjRITD25H4DnOQClLA4/j7jLGXXLVKxAug==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"node": ">= 10"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/replace-homedir": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/replace-homedir/-/replace-homedir-2.0.0.tgz",
"integrity": "sha512-bgEuQQ/BHW0XkkJtawzrfzHFSN70f/3cNOiHa2QsYxqrjaC30X1k74FJ6xswVBP0sr0SpGIdVFuPwfrYziVeyw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/replacestream": {
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/replacestream/-/replacestream-4.0.3.tgz",
"integrity": "sha512-AC0FiLS352pBBiZhd4VXB1Ab/lh0lEgpP+GGvZqbQh8a5cmXVoTe5EX/YeTFArnp4SRGTHh1qCHu9lGs1qG8sA==",
"dev": true,
"dependencies": {
"escape-string-regexp": "^1.0.3",
"object-assign": "^4.0.1",
"readable-stream": "^2.0.2"
}
},
"node_modules/require-directory": {
"version": "2.1.1",
"resolved": "https://registry.npmjs.org/require-directory/-/require-directory-2.1.1.tgz",
"integrity": "sha1-jGStX9MNqxyXbiNE/+f3kqam30I=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/require-from-string": {
"version": "2.0.2",
"resolved": "https://registry.npmjs.org/require-from-string/-/require-from-string-2.0.2.tgz",
"integrity": "sha512-Xf0nWe6RseziFMu+Ap9biiUbmplq6S9/p+7w7YXP/JBHhrUDDUhwa+vANyubuqfZWTveU//DYVGsDG7RKL/vEw==",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/require-one": {
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/require-one/-/require-one-1.0.3.tgz",
"integrity": "sha512-5nXixwgbAZfQ65g7fXv5fDXYRiKByOT1NT3EffS+0W/1MoF+Lkbsly3MXIlPIAgEtspX5fWAbXnp6d4BNMx+xQ==",
"dev": true,
"license": "MIT"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/requizzle": {
"version": "0.2.3",
"resolved": "https://registry.npmjs.org/requizzle/-/requizzle-0.2.3.tgz",
"integrity": "sha512-YanoyJjykPxGHii0fZP0uUPEXpvqfBDxWV7s6GKAiiOsiqhX6vHNyW3Qzdmqp/iq/ExbhaGbVrjB4ruEVSM4GQ==",
"dev": true,
"dependencies": {
"lodash": "^4.17.14"
}
},
"node_modules/resolve": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "1.22.4",
"resolved": "https://registry.npmjs.org/resolve/-/resolve-1.22.4.tgz",
"integrity": "sha512-PXNdCiPqDqeUou+w1C2eTQbNfxKSuMxqTCuvlmmMsk1NWHL5fRrhY6Pl0qEYYc6+QqGClco1Qj8XnjPego4wfg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2023-08-06 09:22:20 +02:00
"is-core-module": "^2.13.0",
Update npm packages
2022-04-17 10:15:10 +02:00
"path-parse": "^1.0.7",
"supports-preserve-symlinks-flag": "^1.0.0"
},
"bin": {
"resolve": "bin/resolve"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/resolve-dir": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/resolve-dir/-/resolve-dir-1.0.1.tgz",
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"integrity": "sha512-R7uiTjECzvOsWSfdM0QKFNBVFcK27aHOUwdvK53BcW8zqnGdYp0Fbj82cy54+2A4P2tFM22J5kRfe1R+lM/1yg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"expand-tilde": "^2.0.0",
"global-modules": "^1.0.0"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/resolve-from": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/resolve-from/-/resolve-from-4.0.0.tgz",
"integrity": "sha512-pb/MYmXstAkysRFx8piNI1tGFNQIFA3vkE3Gq4EuA1dF6gHp/+vgZqsCGJapvy8N3Q+4o7FwvquPJcnZ7RYy4g==",
"dev": true,
"engines": {
"node": ">=4"
}
},
"node_modules/resolve-options": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/resolve-options/-/resolve-options-2.0.0.tgz",
"integrity": "sha512-/FopbmmFOQCfsCx77BRFdKOniglTiHumLgwvd6IDPihy1GKkadZbgQJBcTb2lMzSR1pndzd96b1nZrreZ7+9/A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"value-or-function": "^4.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/ret": {
"version": "0.1.15",
"resolved": "https://registry.npmjs.org/ret/-/ret-0.1.15.tgz",
"integrity": "sha512-TTlYpa+OL+vMMNG24xSlQGEJ3B/RzEfUlLct7b5G/ytav+wPrplCpVMFuwzXbkecJrb6IYo1iFb0S9v37754mg==",
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"peer": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=0.12"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/retry": {
"version": "0.12.0",
"resolved": "https://registry.npmjs.org/retry/-/retry-0.12.0.tgz",
"integrity": "sha512-9LkiTwjUh6rT555DtE9rTX+BKByPfrMzEAtnlEtdEwr3Nkffwiihqe2bWADg+OQRjt9gl6ICdmB/ZFDCGAtSow==",
"dev": true,
"engines": {
"node": ">= 4"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/reusify": {
"version": "1.0.4",
"resolved": "https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz",
"integrity": "sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==",
"dev": true,
"engines": {
"iojs": ">=1.0.0",
"node": ">=0.10.0"
}
},
"node_modules/rimraf": {
Revert "Update `rimraf` to version 4" This reverts commit 32357e3d172a552e0408b3e1ed743e87fe7d5a21.
2023-03-06 19:47:18 +01:00
"version": "3.0.2",
"resolved": "https://registry.npmjs.org/rimraf/-/rimraf-3.0.2.tgz",
"integrity": "sha512-JZkJMZkAGFFPP2YqXZXPbMlMBgsxzE8ILs4lMIX/2o0L9UBw9O/Y3o6wFw/i9YLapcUJWwqbi3kdxIPdC62TIA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Revert "Update `rimraf` to version 4" This reverts commit 32357e3d172a552e0408b3e1ed743e87fe7d5a21.
2023-03-06 19:47:18 +01:00
"dependencies": {
"glob": "^7.1.3"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"bin": {
Revert "Update `rimraf` to version 4" This reverts commit 32357e3d172a552e0408b3e1ed743e87fe7d5a21.
2023-03-06 19:47:18 +01:00
"rimraf": "bin.js"
},
"funding": {
"url": "https://github.com/sponsors/isaacs"
}
},
"node_modules/rimraf/node_modules/glob": {
"version": "7.1.6",
"resolved": "https://registry.npmjs.org/glob/-/glob-7.1.6.tgz",
"integrity": "sha512-LwaxwyZ72Lk7vZINtNNrywX0ZuLyStrdDtabefZKAY5ZGJhVtgdznluResxNmPitE0SAO+O26sWTHeKSI2wMBA==",
"dev": true,
"dependencies": {
"fs.realpath": "^1.0.0",
"inflight": "^1.0.4",
"inherits": "2",
"minimatch": "^3.0.4",
"once": "^1.3.0",
"path-is-absolute": "^1.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Revert "Update `rimraf` to version 4" This reverts commit 32357e3d172a552e0408b3e1ed743e87fe7d5a21.
2023-03-06 19:47:18 +01:00
"node": "*"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
"url": "https://github.com/sponsors/isaacs"
}
},
"node_modules/run-parallel": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.2.0.tgz",
"integrity": "sha512-5l4VyZR86LZ/lDxZTR6jqL8AFE2S0IFLMP26AbjsLVADxHdhB/c0GUsH+y39UfCi3dzz8OlQuPmnaJOMoDHQBA==",
"dev": true,
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/feross"
},
{
"type": "patreon",
"url": "https://www.patreon.com/feross"
},
{
"type": "consulting",
"url": "https://feross.org/support"
}
],
"dependencies": {
"queue-microtask": "^1.2.2"
}
},
Update npm packages
2023-08-06 09:22:20 +02:00
"node_modules/safe-array-concat": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/safe-array-concat/-/safe-array-concat-1.0.0.tgz",
"integrity": "sha512-9dVEFruWIsnie89yym+xWTAYASdpw3CJV7Li/6zBewGf9z2i1j31rP6jnY0pHEO4QZh6N0K11bFjWmdR8UGdPQ==",
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
"get-intrinsic": "^1.2.0",
"has-symbols": "^1.0.3",
"isarray": "^2.0.5"
},
"engines": {
"node": ">=0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/safe-array-concat/node_modules/isarray": {
"version": "2.0.5",
"resolved": "https://registry.npmjs.org/isarray/-/isarray-2.0.5.tgz",
"integrity": "sha512-xHjhDr3cNBK0BzdUJSPXZntQUx/mwMS5Rw4A7lPJ90XGAO6ISP/ePDNuo0vhqOZU+UD5JoodwCAAoZQd3FeAKw==",
"dev": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/safe-buffer": {
"version": "5.1.2",
"resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz",
"integrity": "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==",
"dev": true
},
"node_modules/safe-regex": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/safe-regex/-/safe-regex-1.1.0.tgz",
"integrity": "sha1-QKNmnzsHfR6UPURinhV91IAjvy4=",
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"peer": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"ret": "~0.1.10"
}
},
Update npm packages
2023-01-15 10:34:56 +01:00
"node_modules/safe-regex-test": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/safe-regex-test/-/safe-regex-test-1.0.0.tgz",
"integrity": "sha512-JBUUzyOgEwXQY1NuPtvcj/qcBDbDmEvWufhlnXZIm75DEHp+afM1r1ujJpJsV/gSM4t59tpDyPi1sd6ZaPFfsA==",
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
"get-intrinsic": "^1.1.3",
"is-regex": "^1.1.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/safer-buffer": {
"version": "2.1.2",
"resolved": "https://registry.npmjs.org/safer-buffer/-/safer-buffer-2.1.2.tgz",
"integrity": "sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==",
"dev": true,
"license": "MIT"
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/schema-utils": {
Update npm packages
2022-10-29 10:17:36 +02:00
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-4.0.0.tgz",
"integrity": "sha512-1edyXKgh6XnJsJSQ8mKWXnN/BVaIbFMLpouRUrXgVq7WYne5kw3MW7UPhO44uRXQSIpTSXoJbmrR2X0w9kUTyg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2022-10-29 10:17:36 +02:00
"@types/json-schema": "^7.0.9",
"ajv": "^8.8.0",
"ajv-formats": "^2.1.1",
"ajv-keywords": "^5.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update npm packages
2022-10-29 10:17:36 +02:00
"node": ">= 12.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
"type": "opencollective",
"url": "https://opencollective.com/webpack"
}
},
Update npm packages
2022-10-29 10:17:36 +02:00
"node_modules/schema-utils/node_modules/ajv": {
"version": "8.11.0",
"resolved": "https://registry.npmjs.org/ajv/-/ajv-8.11.0.tgz",
"integrity": "sha512-wGgprdCvMalC0BztXvitD2hC04YffAvtsUn93JbGXYLAtCUO4xd17mCCZQxUOItiBwZvJScWo8NIvQMQ71rdpg==",
"dev": true,
"dependencies": {
"fast-deep-equal": "^3.1.1",
"json-schema-traverse": "^1.0.0",
"require-from-string": "^2.0.2",
"uri-js": "^4.2.2"
},
"funding": {
"type": "github",
"url": "https://github.com/sponsors/epoberezkin"
}
},
"node_modules/schema-utils/node_modules/ajv-keywords": {
"version": "5.1.0",
"resolved": "https://registry.npmjs.org/ajv-keywords/-/ajv-keywords-5.1.0.tgz",
"integrity": "sha512-YCS/JNFAUyr5vAuhk1DWm1CBxRHW9LbJ2ozWeemrIqpbsqKjHVxYPyi5GC0rjZIT5JxJ3virVTS8wk4i/Z+krw==",
"dev": true,
"dependencies": {
"fast-deep-equal": "^3.1.3"
},
"peerDependencies": {
"ajv": "^8.8.2"
}
},
"node_modules/schema-utils/node_modules/json-schema-traverse": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz",
"integrity": "sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==",
"dev": true
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/section-matter": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/section-matter/-/section-matter-1.0.0.tgz",
"integrity": "sha512-vfD3pmTzGpufjScBh50YHKzEu2lxBWhVEHsNGoEXmCmn2hKGfeNLYMzCJpe8cD7gqX7TJluOVpBkAequ6dgMmA==",
"dev": true,
"license": "MIT",
"dependencies": {
"extend-shallow": "^2.0.1",
"kind-of": "^6.0.0"
},
"engines": {
"node": ">=4"
}
},
"node_modules/section-matter/node_modules/extend-shallow": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/extend-shallow/-/extend-shallow-2.0.1.tgz",
"integrity": "sha512-zCnTtlxNoAiDc3gqY2aYAWFx7XWWiasuF2K8Me5WbN8otHKTUKBwjPtNpRs/rbUZm7KxWAaNj7P1a/p52GbVug==",
"dev": true,
"license": "MIT",
"dependencies": {
"is-extendable": "^0.1.0"
},
"engines": {
"node": ">=0.10.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/semver": {
Fix dependency vulnerabilities with `npm audit fix`
2023-10-14 13:46:57 +02:00
"version": "5.7.2",
"resolved": "https://registry.npmjs.org/semver/-/semver-5.7.2.tgz",
"integrity": "sha512-cBznnQ9KjJqU67B52RMC65CMarK2600WFnbkcaiwWq3xy/5haFJlshgnpjovMVJ+Hff49d8GEn0b87C5pDQ10g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"bin": {
"semver": "bin/semver"
}
},
"node_modules/semver-greatest-satisfied-range": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/semver-greatest-satisfied-range/-/semver-greatest-satisfied-range-2.0.0.tgz",
"integrity": "sha512-lH3f6kMbwyANB7HuOWRMlLCa2itaCrZJ+SAqqkSZrZKO/cAsk2EOyaKHUtNkVLFyFW9pct22SFesFp3Z7zpA0g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"sver": "^1.8.3"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/serialize-javascript": {
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"version": "6.0.2",
"resolved": "https://registry.npmjs.org/serialize-javascript/-/serialize-javascript-6.0.2.tgz",
"integrity": "sha512-Saa1xPByTTq2gdeFZYLLo+RFE35NHZkAbqZeWNd3BpzppeVisAqpDjcp8dyf6uIvEqJRd46jemmyA4iFIeVk8g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"randombytes": "^2.1.0"
}
},
"node_modules/set-blocking": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/set-blocking/-/set-blocking-2.0.0.tgz",
"integrity": "sha1-BF+XgtARrppoA93TgrJDkrPYkPc=",
"dev": true
},
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"node_modules/set-function-name": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/set-function-name/-/set-function-name-2.0.1.tgz",
"integrity": "sha512-tMNCiqYVkXIZgc2Hnoy2IvC/f8ezc5koaRFkCjrpWzGpCd3qbZXPzVy9MAZzK1ch/X0jvSkojys3oqJN0qCmdA==",
"dev": true,
"peer": true,
"dependencies": {
"define-data-property": "^1.0.1",
"functions-have-names": "^1.2.3",
"has-property-descriptors": "^1.0.0"
},
"engines": {
"node": ">= 0.4"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/side-channel": {
"version": "1.0.4",
"resolved": "https://registry.npmjs.org/side-channel/-/side-channel-1.0.4.tgz",
"integrity": "sha512-q5XPytqFEIKHkGdiMIrY10mvLRvnQh42/+GoBlFW3b2LXLE2xxJpZFdm94we0BaoV3RwJyGqg5wS7epxTv0Zvw==",
"dev": true,
"dependencies": {
"call-bind": "^1.0.0",
"get-intrinsic": "^1.0.2",
"object-inspect": "^1.9.0"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/signal-exit": {
Update npm packages
2022-02-20 10:08:23 +01:00
"version": "3.0.7",
"resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-3.0.7.tgz",
"integrity": "sha512-wnD2ZE+l+SPC/uoS0vXeE9L1+0wuaMqKlfz9AMUo38JsyLSBWSFcHR1Rri62LZc12vLr1gb3jl7iwQhgwpAbGQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
"node_modules/simple-concat": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/simple-concat/-/simple-concat-1.0.1.tgz",
"integrity": "sha512-cSFtAPtRhljv69IK0hTVZQ+OfE9nePi/rtJmw5UjHeVyVroEqJXP1sFztKUy1qU+xvz3u/sfYJLa947b7nAN2Q==",
"dev": true,
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/feross"
},
{
"type": "patreon",
"url": "https://www.patreon.com/feross"
},
{
"type": "consulting",
"url": "https://feross.org/support"
}
]
},
"node_modules/simple-get": {
Bump simple-get from 3.1.0 to 3.1.1 Bumps [simple-get](https://github.com/feross/simple-get) from 3.1.0 to 3.1.1. - [Release notes](https://github.com/feross/simple-get/releases) - [Commits](https://github.com/feross/simple-get/compare/v3.1.0...v3.1.1) --- updated-dependencies: - dependency-name: simple-get dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
2022-02-06 12:14:16 +00:00
"version": "3.1.1",
"resolved": "https://registry.npmjs.org/simple-get/-/simple-get-3.1.1.tgz",
"integrity": "sha512-CQ5LTKGfCpvE1K0n2us+kuMPbk/q0EKl82s4aheV9oXjFEz6W/Y7oQFVJuU6QG77hRT4Ghb5RURteF5vnWjupA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"decompress-response": "^4.2.0",
"once": "^1.3.1",
"simple-concat": "^1.0.0"
}
},
"node_modules/slash": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/slash/-/slash-3.0.0.tgz",
"integrity": "sha512-g9Q1haeby36OSStwb4ntCGGGaKsaVSjQ68fBxoQcutl5fS1vuY18H3wSt3jFyFtrkx+Kz0V1G85A4MyAdDMi2Q==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/slice-ansi": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/slice-ansi/-/slice-ansi-4.0.0.tgz",
"integrity": "sha512-qMCMfhY040cVHT43K9BFygqYbUPFZKHOg7K73mtTWJRb8pyP3fzf4Ixd5SzdEJQ6MRUg/WBnOLxghZtKKurENQ==",
"dev": true,
"dependencies": {
"ansi-styles": "^4.0.0",
"astral-regex": "^2.0.0",
"is-fullwidth-code-point": "^3.0.0"
},
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/chalk/slice-ansi?sponsor=1"
}
},
"node_modules/slice-ansi/node_modules/ansi-styles": {
"version": "4.3.0",
"resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz",
"integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==",
"dev": true,
"dependencies": {
"color-convert": "^2.0.1"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/chalk/ansi-styles?sponsor=1"
}
},
"node_modules/slice-ansi/node_modules/color-convert": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz",
"integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==",
"dev": true,
"dependencies": {
"color-name": "~1.1.4"
},
"engines": {
"node": ">=7.0.0"
}
},
"node_modules/slice-ansi/node_modules/is-fullwidth-code-point": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
"integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
"dev": true,
"engines": {
"node": ">=8"
}
},
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"node_modules/smart-buffer": {
"version": "4.2.0",
"resolved": "https://registry.npmjs.org/smart-buffer/-/smart-buffer-4.2.0.tgz",
"integrity": "sha512-94hK0Hh8rPqQl2xXc3HsaBoOXKV20MToPkcXvwbISWLEs+64sBq5kFgn2kJDHb1Pry9yrP0dxrCI9RRci7RXKg==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"engines": {
"node": ">= 6.0.0",
"npm": ">= 3.0.0"
}
},
"node_modules/socks": {
Update dependencies to the most recent versions
2024-04-11 15:40:38 +02:00
"version": "2.8.3",
"resolved": "https://registry.npmjs.org/socks/-/socks-2.8.3.tgz",
"integrity": "sha512-l5x7VUUWbjVFbafGLxPWkYsHIhEvmF85tbIeFZWc8ZPtoMyybuEhL7Jye/ooC4/d48FgOjSJXgsF/AJPYCW8Zw==",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dependencies": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"ip-address": "^9.0.5",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"smart-buffer": "^4.2.0"
},
"engines": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"node": ">= 10.0.0",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"npm": ">= 3.0.0"
}
},
"node_modules/socks-proxy-agent": {
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"version": "8.0.4",
"resolved": "https://registry.npmjs.org/socks-proxy-agent/-/socks-proxy-agent-8.0.4.tgz",
"integrity": "sha512-GNAq/eg8Udq2x0eNiFkr9gRg5bA7PXEWagQdeRX4cPSG+X/8V38v637gim9bjFptMk1QWsCTr0ttrJEiXbNnRw==",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-04-03 14:42:19 +02:00
"agent-base": "^7.1.1",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"debug": "^4.3.4",
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"socks": "^2.8.3"
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
},
"engines": {
"node": ">= 14"
}
},
"node_modules/socks-proxy-agent/node_modules/agent-base": {
Update dependencies to the most recent versions
2024-04-03 14:42:19 +02:00
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/agent-base/-/agent-base-7.1.1.tgz",
"integrity": "sha512-H0TSyFNDMomMNJQBn8wFV5YC/2eJ+VXECwOadZJT554xP6cODZHPX3H9QMQECxvrgiSOP1pHjy1sMWQVYJOUOA==",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dependencies": {
"debug": "^4.3.4"
},
"engines": {
"node": ">= 14"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/source-map": {
"version": "0.6.1",
"resolved": "https://registry.npmjs.org/source-map/-/source-map-0.6.1.tgz",
"integrity": "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g==",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/source-map-js": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/source-map-js/-/source-map-js-1.2.0.tgz",
"integrity": "sha512-itJW8lvSA0TXEphiRoawsCksnlf8SyvmFzIhltqAHluXd88pkCd+cXJVHTDwdCr0IzwptSm035IHQktUu1QUMg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/source-map-support": {
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"version": "0.5.21",
"resolved": "https://registry.npmjs.org/source-map-support/-/source-map-support-0.5.21.tgz",
"integrity": "sha512-uBHU3L3czsIyYXKX88fdrGovxdSCoTGDRZ6SYXtSRxLZUzHg5P/66Ht6uoUlHu9EZod+inXhKo3qQgwXUT/y1w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"buffer-from": "^1.0.0",
"source-map": "^0.6.0"
}
},
"node_modules/sparkles": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/sparkles/-/sparkles-2.1.0.tgz",
"integrity": "sha512-r7iW1bDw8R/cFifrD3JnQJX0K1jqT0kprL48BiBpLZLJPmAm34zsVBsK5lc7HirZYZqMW65dOXZgbAGt/I6frg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/spdx-correct": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/spdx-correct/-/spdx-correct-3.0.0.tgz",
"integrity": "sha512-N19o9z5cEyc8yQQPukRCZ9EUmb4HUpnrmaL/fxS2pBo2jbfcFRVuFZ/oFC+vZz0MNNk0h80iMn5/S6qGZOL5+g==",
"dev": true,
"dependencies": {
"spdx-expression-parse": "^3.0.0",
"spdx-license-ids": "^3.0.0"
}
},
"node_modules/spdx-exceptions": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/spdx-exceptions/-/spdx-exceptions-2.1.0.tgz",
"integrity": "sha512-4K1NsmrlCU1JJgUrtgEeTVyfx8VaYea9J9LvARxhbHtVtohPs/gFGG5yy49beySjlIMhhXZ4QqujIZEfS4l6Cg==",
"dev": true
},
"node_modules/spdx-expression-parse": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/spdx-expression-parse/-/spdx-expression-parse-3.0.0.tgz",
"integrity": "sha512-Yg6D3XpRD4kkOmTpdgbUiEJFKghJH03fiC1OPll5h/0sO6neh2jqRDVHOQ4o/LMea0tgCkbMgea5ip/e+MkWyg==",
"dev": true,
"dependencies": {
"spdx-exceptions": "^2.1.0",
"spdx-license-ids": "^3.0.0"
}
},
"node_modules/spdx-license-ids": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/spdx-license-ids/-/spdx-license-ids-3.0.0.tgz",
"integrity": "sha512-2+EPwgbnmOIl8HjGBXXMd9NAu02vLjOO1nWw4kmeRDFyHn+M/ETfHxQUK0oXg8ctgVnl9t3rosNVsZ1jG61nDA==",
"dev": true
},
"node_modules/sprintf-js": {
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/sprintf-js/-/sprintf-js-1.0.3.tgz",
"integrity": "sha1-BOaSb2YolTVPPdAVIDYzuFcpfiw=",
"dev": true
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/stat-mode": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/stat-mode/-/stat-mode-1.0.0.tgz",
"integrity": "sha512-jH9EhtKIjuXZ2cWxmXS8ZP80XyC3iasQxMDV8jzhNJpfDb7VbQLVW4Wvsxz9QZvzV+G4YoSfBUVKDOyxLzi/sg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node": ">= 6"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/stream-composer": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/stream-composer/-/stream-composer-1.0.2.tgz",
"integrity": "sha512-bnBselmwfX5K10AH6L4c8+S5lgZMWI7ZYrz2rvYjCPB2DIMC4Ig8OpxGpNJSxRZ58oti7y1IcNvjBAz9vW5m4w==",
"dev": true,
"license": "MIT",
"dependencies": {
"streamx": "^2.13.2"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/stream-exhaust": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/stream-exhaust/-/stream-exhaust-1.0.2.tgz",
"integrity": "sha512-b/qaq/GlBK5xaq1yrK9/zFcyRSTNxmcZwFLGSTG0mXgZl/4Z6GgiyYOXOvY7N3eEvFRAG1bkDRz5EPGSvPYQlw==",
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"dev": true,
"license": "MIT"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"node_modules/streamx": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "2.18.0",
"resolved": "https://registry.npmjs.org/streamx/-/streamx-2.18.0.tgz",
"integrity": "sha512-LLUC1TWdjVdn1weXGcSxyTR3T4+acB6tVGXT95y0nGbca4t4o/ng1wKAGTljm9VicuCVLvRlqFYXYy5GwgM7sQ==",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"dev": true,
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"license": "MIT",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"fast-fifo": "^1.3.2",
"queue-tick": "^1.0.1",
"text-decoder": "^1.1.0"
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
},
"optionalDependencies": {
"bare-events": "^2.2.0"
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/string_decoder": {
"version": "1.1.1",
"resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.1.1.tgz",
"integrity": "sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg==",
"dev": true,
"dependencies": {
"safe-buffer": "~5.1.0"
}
},
"node_modules/string-width": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-1.0.2.tgz",
"integrity": "sha1-EYvfW4zcUaKn5w0hHgfisLmxB9M=",
"dev": true,
"dependencies": {
"code-point-at": "^1.0.0",
"is-fullwidth-code-point": "^1.0.0",
"strip-ansi": "^3.0.0"
},
"engines": {
"node": ">=0.10.0"
}
},
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node_modules/string-width-cjs": {
"name": "string-width",
"version": "4.2.3",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
"integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
"dev": true,
"dependencies": {
"emoji-regex": "^8.0.0",
"is-fullwidth-code-point": "^3.0.0",
"strip-ansi": "^6.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/string-width-cjs/node_modules/ansi-regex": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
"integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/string-width-cjs/node_modules/is-fullwidth-code-point": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
"integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/string-width-cjs/node_modules/strip-ansi": {
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
"integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
"dev": true,
"dependencies": {
"ansi-regex": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/string.prototype.matchall": {
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"version": "4.0.10",
"resolved": "https://registry.npmjs.org/string.prototype.matchall/-/string.prototype.matchall-4.0.10.tgz",
"integrity": "sha512-rGXbGmOEosIQi6Qva94HUjgPs9vKW+dkG7Y8Q5O2OYkWL6wFaTRZO8zM4mhP94uX55wgyrXzfS2aGtGzUL7EJQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update npm packages
2022-09-18 10:31:32 +02:00
"peer": true,
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"call-bind": "^1.0.2",
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"define-properties": "^1.2.0",
"es-abstract": "^1.22.1",
"get-intrinsic": "^1.2.1",
Update npm packages
2022-09-18 10:31:32 +02:00
"has-symbols": "^1.0.3",
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"internal-slot": "^1.0.5",
"regexp.prototype.flags": "^1.5.0",
"set-function-name": "^2.0.0",
Update npm packages
2022-09-18 10:31:32 +02:00
"side-channel": "^1.0.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Update npm packages
2023-08-06 09:22:20 +02:00
"node_modules/string.prototype.trim": {
"version": "1.2.7",
"resolved": "https://registry.npmjs.org/string.prototype.trim/-/string.prototype.trim-1.2.7.tgz",
"integrity": "sha512-p6TmeT1T3411M8Cgg9wBTMRtY2q9+PNy9EV1i2lIXUN/btt763oIfxwN3RR8VU6wHX8j/1CFy0L+YuThm6bgOg==",
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
"define-properties": "^1.1.4",
"es-abstract": "^1.20.4"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Update npm packages
2022-09-18 10:31:32 +02:00
"node_modules/string.prototype.trimend": {
Update npm packages
2023-01-15 10:34:56 +01:00
"version": "1.0.6",
"resolved": "https://registry.npmjs.org/string.prototype.trimend/-/string.prototype.trimend-1.0.6.tgz",
"integrity": "sha512-JySq+4mrPf9EsDBEDYMOb/lM7XQLulwg5R/m1r0PXEFqrV0qHvl58sdTilSXtKOflCsK2E8jxf+GKC0T07RWwQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2022-09-18 10:31:32 +02:00
"call-bind": "^1.0.2",
"define-properties": "^1.1.4",
Update npm packages
2023-01-15 10:34:56 +01:00
"es-abstract": "^1.20.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Update npm packages
2022-09-18 10:31:32 +02:00
"funding": {
"url": "https://github.com/sponsors/ljharb"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/string.prototype.trimstart": {
Update npm packages
2023-01-15 10:34:56 +01:00
"version": "1.0.6",
"resolved": "https://registry.npmjs.org/string.prototype.trimstart/-/string.prototype.trimstart-1.0.6.tgz",
"integrity": "sha512-omqjMDaY92pbn5HOX7f9IccLA+U1tA9GvtU4JrodiXFfYB7jPzzHpRzpglLAjtUV6bB557zwClJezTqnAiYnQA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
Update npm packages
2022-09-18 10:31:32 +02:00
"define-properties": "^1.1.4",
Update npm packages
2023-01-15 10:34:56 +01:00
"es-abstract": "^1.20.4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/strip-ansi": {
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-3.0.1.tgz",
"integrity": "sha1-ajhfuIU9lS1f8F0Oiq+UJ43GPc8=",
"dev": true,
"dependencies": {
"ansi-regex": "^2.0.0"
},
"engines": {
"node": ">=0.10.0"
}
},
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node_modules/strip-ansi-cjs": {
"name": "strip-ansi",
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
"integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
"dev": true,
"dependencies": {
"ansi-regex": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/strip-ansi-cjs/node_modules/ansi-regex": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
"integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/strip-bom-string": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/strip-bom-string/-/strip-bom-string-1.0.0.tgz",
"integrity": "sha512-uCC2VHvQRYu+lMh4My/sFNmF2klFymLX1wHJeXnbEJERpV/ZsVuonzerjfrGpIGF7LBVa1O7i9kjiWvJiFck8g==",
"dev": true,
"license": "MIT",
"engines": {
"node": ">=0.10.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/strip-indent": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/strip-indent/-/strip-indent-3.0.0.tgz",
"integrity": "sha512-laJTa3Jb+VQpaC6DseHhF7dXVqHTfJPCRDaEbid/drOhgitgYku/letMUqOXFoWV0zIIUbjpdH2t+tYj4bQMRQ==",
"dev": true,
"dependencies": {
"min-indent": "^1.0.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/strip-json-comments": {
"version": "3.1.1",
"resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-3.1.1.tgz",
"integrity": "sha512-6fPc+R4ihwqP6N/aIv2f1gMH8lOVtWQHoqC4yK6oSDVVocumAsfCqjkXnqiYMhmMwS/mEHLp7Vehlt3ql6lEig==",
"dev": true,
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
},
"node_modules/stylelint": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "16.7.0",
"resolved": "https://registry.npmjs.org/stylelint/-/stylelint-16.7.0.tgz",
"integrity": "sha512-Q1ATiXlz+wYr37a7TGsfvqYn2nSR3T/isw3IWlZQzFzCNoACHuGBb6xBplZXz56/uDRJHIygxjh7jbV/8isewA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"funding": [
{
"type": "opencollective",
"url": "https://opencollective.com/stylelint"
},
{
"type": "github",
"url": "https://github.com/sponsors/stylelint"
}
],
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"@csstools/css-parser-algorithms": "^2.7.1",
"@csstools/css-tokenizer": "^2.4.1",
"@csstools/media-query-list-parser": "^2.1.13",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"@csstools/selector-specificity": "^3.1.1",
"@dual-bundle/import-meta-resolve": "^4.1.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"balanced-match": "^2.0.0",
Update npm packages
2022-09-04 09:57:59 +02:00
"colord": "^2.9.3",
Update npm packages
2023-12-23 12:29:51 +01:00
"cosmiconfig": "^9.0.0",
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"css-functions-list": "^3.2.2",
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"css-tree": "^2.3.1",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"debug": "^4.3.5",
Update npm packages
2023-12-23 12:29:51 +01:00
"fast-glob": "^3.3.2",
Update npm packages
2022-08-21 09:54:06 +02:00
"fastest-levenshtein": "^1.0.16",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"file-entry-cache": "^9.0.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"global-modules": "^2.0.0",
Update npm packages
2022-02-06 11:24:14 +01:00
"globby": "^11.1.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"globjoin": "^0.1.4",
Update packages to the most recent versions
2023-04-23 13:48:22 +02:00
"html-tags": "^3.3.1",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"ignore": "^5.3.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"imurmurhash": "^0.1.4",
"is-plain-object": "^5.0.0",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"known-css-properties": "^0.34.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"mathml-tag-names": "^2.1.3",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"meow": "^13.2.0",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"micromatch": "^4.0.7",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"normalize-path": "^3.0.0",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"picocolors": "^1.0.1",
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"postcss": "^8.4.39",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"postcss-resolve-nested-selector": "^0.1.1",
Update npm packages
2023-12-23 12:29:51 +01:00
"postcss-safe-parser": "^7.0.0",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"postcss-selector-parser": "^6.1.0",
Update npm packages
2022-02-06 11:24:14 +01:00
"postcss-value-parser": "^4.2.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"resolve-from": "^5.0.0",
"string-width": "^4.2.3",
Update npm packages
2023-12-23 12:29:51 +01:00
"strip-ansi": "^7.1.0",
Update npm packages
2023-03-25 09:41:15 +01:00
"supports-hyperlinks": "^3.0.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"svg-tags": "^1.0.0",
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"table": "^6.8.2",
Update npm packages
2023-05-14 10:12:06 +02:00
"write-file-atomic": "^5.0.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"bin": {
Update Stylelint to the latest version Trying to update Stylelint to version `15.10.1`, and beyond, broke linting. Looking at the changes the issue appears to be that the `bin/stylelint.js` file was replaced with `bin/stylelint.mjs` instead, which our `gulp lint` runner wasn't able to automatically find; see https://github.com/stylelint/stylelint/compare/15.10.0...15.10.1
2023-07-22 11:34:14 +02:00
"stylelint": "bin/stylelint.mjs"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update npm packages
2023-12-23 12:29:51 +01:00
"node": ">=18.12.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/stylelint-prettier": {
Update npm packages
2023-12-23 12:29:51 +01:00
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/stylelint-prettier/-/stylelint-prettier-5.0.0.tgz",
"integrity": "sha512-RHfSlRJIsaVg5Br94gZVdWlz/rBTyQzZflNE6dXvSxt/GthWMY3gEHsWZEBaVGg7GM+XrtVSp4RznFlB7i0oyw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"prettier-linter-helpers": "^1.0.0"
},
"engines": {
Update npm packages
2023-12-23 12:29:51 +01:00
"node": ">=18.12.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependencies": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"prettier": ">=3.0.0",
Update npm packages
2023-12-23 12:29:51 +01:00
"stylelint": ">=16.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/stylelint/node_modules/ansi-regex": {
Update npm packages
2023-12-23 12:29:51 +01:00
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.0.1.tgz",
"integrity": "sha512-n5M855fKb2SsfMIiFFoVrABHJC8QtHwVx+mHWP3QcEqBHYienj5dHSgjbxtC0WEZXYt4wcD6zrQElDPhFuZgfA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Update npm packages
2023-12-23 12:29:51 +01:00
"node": ">=12"
},
"funding": {
"url": "https://github.com/chalk/ansi-regex?sponsor=1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/stylelint/node_modules/balanced-match": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-2.0.0.tgz",
"integrity": "sha512-1ugUSr8BHXRnK23KfuYS+gVMC3LB8QGH9W1iGtDPsNWoQbgtXSExkBu2aDR4epiGWZOjZsj6lDl/N/AqqTC3UA==",
"dev": true
},
"node_modules/stylelint/node_modules/braces": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"version": "3.0.3",
"resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
"integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"fill-range": "^7.1.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=8"
}
},
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"node_modules/stylelint/node_modules/debug": {
"version": "4.3.5",
"resolved": "https://registry.npmjs.org/debug/-/debug-4.3.5.tgz",
"integrity": "sha512-pt0bNEmneDIvdL1Xsd9oDQ/wrQRkXDT4AUWlNZNPKvW5x/jyO9VFXkJUP07vQ2upmw5PlaITaPKc31jK13V+jg==",
"dev": true,
"license": "MIT",
"dependencies": {
"ms": "2.1.2"
},
"engines": {
"node": ">=6.0"
},
"peerDependenciesMeta": {
"supports-color": {
"optional": true
}
}
},
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"node_modules/stylelint/node_modules/file-entry-cache": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"version": "9.0.0",
"resolved": "https://registry.npmjs.org/file-entry-cache/-/file-entry-cache-9.0.0.tgz",
"integrity": "sha512-6MgEugi8p2tiUhqO7GnPsmbCCzj0YRCwwaTbpGRyKZesjRSzkqkAE9fPp7V2yMs5hwfgbQLgdvSSkGNg1s5Uvw==",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"flat-cache": "^5.0.0"
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
},
"engines": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"node": ">=18"
Update dependencies to the most recent versions
2023-10-29 14:22:30 +01:00
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/stylelint/node_modules/fill-range": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
"integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"to-regex-range": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
Update npm packages
2024-01-06 10:09:12 +01:00
"node_modules/stylelint/node_modules/flat-cache": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/flat-cache/-/flat-cache-5.0.0.tgz",
"integrity": "sha512-JrqFmyUl2PnPi1OvLyTVHnQvwQ0S+e6lGSwu8OkAZlSaNIZciTY2H/cOOROxsBA1m/LZNHDsqAgDZt6akWcjsQ==",
Update npm packages
2024-01-06 10:09:12 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2024-01-06 10:09:12 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"flatted": "^3.3.1",
"keyv": "^4.5.4"
Update npm packages
2024-01-06 10:09:12 +01:00
},
"engines": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"node": ">=18"
Update npm packages
2024-01-06 10:09:12 +01:00
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/stylelint/node_modules/global-modules": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/global-modules/-/global-modules-2.0.0.tgz",
"integrity": "sha512-NGbfmJBp9x8IxyJSd1P+otYK8vonoJactOogrVfFRIAEY1ukil8RSKDz2Yo7wh1oihl51l/r6W4epkeKJHqL8A==",
"dev": true,
"dependencies": {
"global-prefix": "^3.0.0"
},
"engines": {
"node": ">=6"
}
},
"node_modules/stylelint/node_modules/global-prefix": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/global-prefix/-/global-prefix-3.0.0.tgz",
"integrity": "sha512-awConJSVCHVGND6x3tmMaKcQvwXLhjdkmomy2W+Goaui8YPgYgXJZewhg3fWC+DlfqqQuWg8AwqjGTD2nAPVWg==",
"dev": true,
"dependencies": {
"ini": "^1.3.5",
"kind-of": "^6.0.2",
"which": "^1.3.1"
},
"engines": {
"node": ">=6"
}
},
"node_modules/stylelint/node_modules/is-fullwidth-code-point": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
"integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/stylelint/node_modules/is-number": {
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
"integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=0.12.0"
}
},
"node_modules/stylelint/node_modules/is-plain-object": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/is-plain-object/-/is-plain-object-5.0.0.tgz",
"integrity": "sha512-VRSzKkbMm5jMDoKLbltAkFQ5Qr7VDiTFGXxYFXXowVj387GeGNOCsOH6Msy00SGZ3Fp84b1Naa1psqgcCIEP5Q==",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/stylelint/node_modules/micromatch": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"version": "4.0.7",
"resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.7.tgz",
"integrity": "sha512-LPP/3KorzCwBxfeUuZmaR6bG2kdeHSbe0P2tY3FLRU4vYrjYz5hI4QZwV0njUx3jeuKe67YukQ1LSPZBKDqO/Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"braces": "^3.0.3",
Update npm packages
2022-04-17 10:15:10 +02:00
"picomatch": "^2.3.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=8.6"
}
},
"node_modules/stylelint/node_modules/normalize-path": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz",
"integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/stylelint/node_modules/resolve-from": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/resolve-from/-/resolve-from-5.0.0.tgz",
"integrity": "sha512-qYg9KP24dD5qka9J47d0aVky0N+b4fTU89LN9iDnjB5waksiC49rvMB0PrUJQGoTmH50XPiqOvAjDfaijGxYZw==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/stylelint/node_modules/string-width": {
"version": "4.2.3",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
"integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
"dev": true,
"dependencies": {
"emoji-regex": "^8.0.0",
"is-fullwidth-code-point": "^3.0.0",
"strip-ansi": "^6.0.1"
},
"engines": {
"node": ">=8"
}
},
Update npm packages
2023-12-23 12:29:51 +01:00
"node_modules/stylelint/node_modules/string-width/node_modules/ansi-regex": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
"integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/stylelint/node_modules/string-width/node_modules/strip-ansi": {
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
"integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
"dev": true,
"dependencies": {
"ansi-regex": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
Update npm packages
2023-12-23 12:29:51 +01:00
"node_modules/stylelint/node_modules/strip-ansi": {
"version": "7.1.0",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.1.0.tgz",
"integrity": "sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==",
"dev": true,
"dependencies": {
"ansi-regex": "^6.0.1"
},
"engines": {
"node": ">=12"
},
"funding": {
"url": "https://github.com/chalk/strip-ansi?sponsor=1"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/stylelint/node_modules/to-regex-range": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
"integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"is-number": "^7.0.0"
},
"engines": {
"node": ">=8.0"
}
},
"node_modules/summary": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/summary/-/summary-2.1.0.tgz",
"integrity": "sha512-nMIjMrd5Z2nuB2RZCKJfFMjgS3fygbeyGk9PxPPaJR1RIcyN9yn4A63Isovzm3ZtQuEkLBVgMdPup8UeLH7aQw==",
"dev": true
},
"node_modules/supports-color": {
"version": "5.4.0",
"resolved": "https://registry.npmjs.org/supports-color/-/supports-color-5.4.0.tgz",
"integrity": "sha512-zjaXglF5nnWpsq470jSv6P9DwPvgLkuapYmfDm3JWOm0vkNTVF2tI4UrN2r6jH1qM/uc/WtxYY1hYoA2dOKj5w==",
"dev": true,
"dependencies": {
"has-flag": "^3.0.0"
},
"engines": {
"node": ">=4"
}
},
Update npm packages
2022-02-06 11:24:14 +01:00
"node_modules/supports-hyperlinks": {
Update npm packages
2023-03-25 09:41:15 +01:00
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/supports-hyperlinks/-/supports-hyperlinks-3.0.0.tgz",
"integrity": "sha512-QBDPHyPQDRTy9ku4URNGY5Lah8PAaXs6tAAwp55sL5WCsSW7GIfdf6W5ixfziW+t7wh3GVvHyHHyQ1ESsoRvaA==",
Update npm packages
2022-02-06 11:24:14 +01:00
"dev": true,
"dependencies": {
"has-flag": "^4.0.0",
"supports-color": "^7.0.0"
},
"engines": {
Update npm packages
2023-03-25 09:41:15 +01:00
"node": ">=14.18"
Update npm packages
2022-02-06 11:24:14 +01:00
}
},
"node_modules/supports-hyperlinks/node_modules/has-flag": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz",
"integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/supports-hyperlinks/node_modules/supports-color": {
"version": "7.2.0",
"resolved": "https://registry.npmjs.org/supports-color/-/supports-color-7.2.0.tgz",
"integrity": "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==",
"dev": true,
"dependencies": {
"has-flag": "^4.0.0"
},
"engines": {
"node": ">=8"
}
},
Update npm packages
2022-04-17 10:15:10 +02:00
"node_modules/supports-preserve-symlinks-flag": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/supports-preserve-symlinks-flag/-/supports-preserve-symlinks-flag-1.0.0.tgz",
"integrity": "sha512-ot0WnXS9fgdkgIcePe6RHNk1WA8+muPa6cSjeR3V8K27q9BB1rTE3R1p7Hv0z1ZyAc8s6Vvv8DIyWf681MAt0w==",
"dev": true,
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/sver": {
"version": "1.8.4",
"resolved": "https://registry.npmjs.org/sver/-/sver-1.8.4.tgz",
"integrity": "sha512-71o1zfzyawLfIWBOmw8brleKyvnbn73oVHNCsu51uPMz/HWiKkkXsI31JjHW5zqXEqnPYkIiHd8ZmL7FCimLEA==",
"dev": true,
"optionalDependencies": {
"semver": "^6.3.0"
}
},
"node_modules/sver/node_modules/semver": {
"version": "6.3.1",
"resolved": "https://registry.npmjs.org/semver/-/semver-6.3.1.tgz",
"integrity": "sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==",
"dev": true,
"optional": true,
"bin": {
"semver": "bin/semver.js"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/svg-tags": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/svg-tags/-/svg-tags-1.0.0.tgz",
"integrity": "sha1-WPcc7jvVGbWdSyqEO2x95krAR2Q=",
"dev": true
},
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node_modules/synckit": {
Update npm packages
2024-01-06 10:09:12 +01:00
"version": "0.8.8",
"resolved": "https://registry.npmjs.org/synckit/-/synckit-0.8.8.tgz",
"integrity": "sha512-HwOKAP7Wc5aRGYdKH+dw0PRRpbO841v2DENBtjnR5HFWoiNByAl7vrx3p0G/rCyYXQsrxqtX48TImFtPcIHSpQ==",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"dev": true,
"dependencies": {
Update npm packages
2024-01-06 10:09:12 +01:00
"@pkgr/core": "^0.1.0",
"tslib": "^2.6.2"
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
},
"engines": {
"node": "^14.18.0 || >=16.0.0"
},
"funding": {
"url": "https://opencollective.com/unts"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/table": {
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"version": "6.8.2",
"resolved": "https://registry.npmjs.org/table/-/table-6.8.2.tgz",
"integrity": "sha512-w2sfv80nrAh2VCbqR5AK27wswXhqcck2AhfnNW76beQXskGZ1V12GwS//yYVa3d3fcvAip2OUnbDAjW2k3v9fA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"ajv": "^8.0.1",
"lodash.truncate": "^4.4.2",
"slice-ansi": "^4.0.0",
"string-width": "^4.2.3",
"strip-ansi": "^6.0.1"
},
"engines": {
"node": ">=10.0.0"
}
},
"node_modules/table/node_modules/ajv": {
Update dependencies to the most recent versions
2024-04-29 19:51:25 +02:00
"version": "8.12.0",
"resolved": "https://registry.npmjs.org/ajv/-/ajv-8.12.0.tgz",
"integrity": "sha512-sRu1kpcO9yLtYxBKvqfTeh9KzZEwO3STyX1HT+4CaDzC6HpTGYhIhPIzj9XuKU7KYDwnaeh5hcOwjy1QuJzBPA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"fast-deep-equal": "^3.1.1",
"json-schema-traverse": "^1.0.0",
"require-from-string": "^2.0.2",
"uri-js": "^4.2.2"
},
"funding": {
"type": "github",
"url": "https://github.com/sponsors/epoberezkin"
}
},
"node_modules/table/node_modules/ansi-regex": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
"integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/table/node_modules/is-fullwidth-code-point": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
"integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/table/node_modules/json-schema-traverse": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-1.0.0.tgz",
"integrity": "sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==",
"dev": true
},
"node_modules/table/node_modules/string-width": {
"version": "4.2.3",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
"integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
"dev": true,
"dependencies": {
"emoji-regex": "^8.0.0",
"is-fullwidth-code-point": "^3.0.0",
"strip-ansi": "^6.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/table/node_modules/strip-ansi": {
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
"integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
"dev": true,
"dependencies": {
"ansi-regex": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/tapable": {
"version": "2.2.1",
"resolved": "https://registry.npmjs.org/tapable/-/tapable-2.2.1.tgz",
"integrity": "sha512-GNzQvQTOIP6RyTfE2Qxb8ZVlNmw0n88vp1szwWRimP02mnTsx3Wtn5qRdqY9w2XduFNUgvOwhNnQsjwCp+kqaQ==",
"dev": true,
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
"node": ">=6"
}
},
"node_modules/tar": {
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-04-11 15:47:06 +02:00
"version": "6.2.1",
"resolved": "https://registry.npmjs.org/tar/-/tar-6.2.1.tgz",
"integrity": "sha512-DZ4yORTwrbTj/7MZYq2w+/ZFdI6OZ/f9SFHR+71gIVUZhOQPHzVCLpvRnPgyaMpfWxxk/4ONva3GQSyNIKRv6A==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"chownr": "^2.0.0",
"fs-minipass": "^2.0.0",
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-04-11 15:47:06 +02:00
"minipass": "^5.0.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"minizlib": "^2.1.1",
"mkdirp": "^1.0.3",
"yallist": "^4.0.0"
},
"engines": {
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-04-11 15:47:06 +02:00
"node": ">=10"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/tar-fs": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"version": "3.0.5",
"resolved": "https://registry.npmjs.org/tar-fs/-/tar-fs-3.0.5.tgz",
"integrity": "sha512-JOgGAmZyMgbqpLwct7ZV8VzkEB6pxXFBVErLtb+XCOqzc6w1xiWKI9GVd6bwk68EX7eJ4DWmfXVmq8K2ziZTGg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"pump": "^3.0.0",
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"tar-stream": "^3.1.5"
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
},
"optionalDependencies": {
"bare-fs": "^2.1.1",
"bare-path": "^2.1.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/tar-stream": {
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"version": "3.1.7",
"resolved": "https://registry.npmjs.org/tar-stream/-/tar-stream-3.1.7.tgz",
"integrity": "sha512-qJj60CXt7IU1Ffyc3NJMjh6EkuCFej46zUqJ4J7pqYlThyd9bO0XBTmcOIhSzZJVWfsLks0+nle/j538YAW9RQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update npm packages
2023-06-25 09:18:41 +02:00
"b4a": "^1.6.4",
"fast-fifo": "^1.2.0",
"streamx": "^2.15.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/tar/node_modules/chownr": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/chownr/-/chownr-2.0.0.tgz",
"integrity": "sha512-bIomtDF5KGpdogkLd9VspvFzk9KfpyyGlS8YFVZl7TGPBHL5snIOnxeshwVgPteQ9b4Eydl+pVbIyE1DcvCWgQ==",
"dev": true,
"engines": {
"node": ">=10"
}
},
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-04-11 15:47:06 +02:00
"node_modules/tar/node_modules/minipass": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/minipass/-/minipass-5.0.0.tgz",
"integrity": "sha512-3FnjYuehv9k6ovOEbyOswadCDPX1piCfhV8ncmYtHOjuPwylVWsghTLo7rabjC3Rx5xD4HDx8Wm1xnMF7S5qFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
Update npm packages
2023-01-28 08:13:13 +01:00
"node_modules/tar/node_modules/mkdirp": {
"version": "1.0.4",
"resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-1.0.4.tgz",
"integrity": "sha512-vVqVZQyf3WLx2Shd0qJ9xuvqgAyKPLAiqITEtqW0oIUjzo3PePDd6fW9iFz30ef7Ysp/oiWqbhszeGWW2T6Gzw==",
"dev": true,
"bin": {
"mkdirp": "bin/cmd.js"
},
"engines": {
"node": ">=10"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/tar/node_modules/yallist": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/yallist/-/yallist-4.0.0.tgz",
"integrity": "sha512-3wdGidZyq5PB084XLES5TpOSRA3wjXAlIWMhum2kRcv/41Sn2emQ0dycQW4uZXLejwKvg6EsvbdlVL+FYEct7A==",
"dev": true
},
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"node_modules/teex": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/teex/-/teex-1.0.1.tgz",
"integrity": "sha512-eYE6iEI62Ni1H8oIa7KlDU6uQBtqr4Eajni3wX7rpfXD8ysFx8z0+dri+KWEPWpBsxXfxu58x/0jvTVT1ekOSg==",
"dev": true,
"dependencies": {
"streamx": "^2.12.5"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/terser": {
Update dependencies to the most recent versions
2024-02-17 15:51:07 +01:00
"version": "5.27.1",
"resolved": "https://registry.npmjs.org/terser/-/terser-5.27.1.tgz",
"integrity": "sha512-29wAr6UU/oQpnTw5HoadwjUZnFQXGdOfj0LjZ4sVxzqwHh/QVkvr7m8y9WoR4iN3FRitVduTc6KdjcW38Npsug==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2023-06-11 11:30:39 +02:00
"@jridgewell/source-map": "^0.3.3",
"acorn": "^8.8.2",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"commander": "^2.20.0",
"source-map-support": "~0.5.20"
},
"bin": {
"terser": "bin/terser"
},
"engines": {
"node": ">=10"
}
},
"node_modules/terser-webpack-plugin": {
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"version": "5.3.10",
"resolved": "https://registry.npmjs.org/terser-webpack-plugin/-/terser-webpack-plugin-5.3.10.tgz",
"integrity": "sha512-BKFPWlPDndPs+NGGCr1U59t0XScL5317Y0UReNrHaw9/FwhPENlq6bfgs+4yPfyP51vqC1bQ4rp1EfXW5ZSH9w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"@jridgewell/trace-mapping": "^0.3.20",
Update npm packages
2023-04-15 22:08:58 +02:00
"jest-worker": "^27.4.5",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"schema-utils": "^3.1.1",
Update npm packages
2023-04-15 22:08:58 +02:00
"serialize-javascript": "^6.0.1",
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"terser": "^5.26.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">= 10.13.0"
},
"funding": {
"type": "opencollective",
"url": "https://opencollective.com/webpack"
},
"peerDependencies": {
"webpack": "^5.1.0"
},
"peerDependenciesMeta": {
"@swc/core": {
"optional": true
},
"esbuild": {
"optional": true
},
"uglify-js": {
"optional": true
}
}
},
"node_modules/terser-webpack-plugin/node_modules/schema-utils": {
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"version": "3.3.0",
"resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-3.3.0.tgz",
"integrity": "sha512-pN/yOAvcC+5rQ5nERGuwrjLlYvLTbCibnZ1I7B1LaiAz9BRBlE9GMgE/eqV30P7aJQUf7Ddimy/RsbYO/GrVGg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"@types/json-schema": "^7.0.8",
"ajv": "^6.12.5",
"ajv-keywords": "^3.5.2"
},
"engines": {
"node": ">= 10.13.0"
},
"funding": {
"type": "opencollective",
"url": "https://opencollective.com/webpack"
}
},
"node_modules/terser/node_modules/commander": {
"version": "2.20.3",
"resolved": "https://registry.npmjs.org/commander/-/commander-2.20.3.tgz",
"integrity": "sha512-GpVkmM8vF2vQUkj2LvZmD35JxeJOLCwJ9cUkugyk2nuhbv3+mJvpLYYt+0+USMxE+oj+ey/lJEnhZw75x/OMcQ==",
"dev": true
},
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"node_modules/text-decoder": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/text-decoder/-/text-decoder-1.1.0.tgz",
"integrity": "sha512-TmLJNj6UgX8xcUZo4UDStGQtDiTzF7BzWlzn9g7UWrjkpHr5uJTK1ld16wZ3LXb2vb6jH8qU89dW5whuMdXYdw==",
"dev": true,
"license": "Apache-2.0",
"dependencies": {
"b4a": "^1.6.4"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/text-table": {
"version": "0.2.0",
"resolved": "https://registry.npmjs.org/text-table/-/text-table-0.2.0.tgz",
"integrity": "sha1-f17oI66AUgfACvLfSoTsP8+lcLQ=",
"dev": true
},
"node_modules/textextensions": {
"version": "3.3.0",
"resolved": "https://registry.npmjs.org/textextensions/-/textextensions-3.3.0.tgz",
"integrity": "sha512-mk82dS8eRABNbeVJrEiN5/UMSCliINAuz8mkUwH4SwslkNP//gbEzlWNS5au0z5Dpx40SQxzqZevZkn+WYJ9Dw==",
"dev": true,
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://bevry.me/fund"
}
},
"node_modules/through": {
"version": "2.3.8",
"resolved": "https://registry.npmjs.org/through/-/through-2.3.8.tgz",
"integrity": "sha1-DdTJ/6q8NXlgsbckEV1+Doai4fU=",
"dev": true
},
"node_modules/time-stamp": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/time-stamp/-/time-stamp-1.1.0.tgz",
"integrity": "sha1-dkpaEa9QVhkhsTPztE5hhofg9cM=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/tmp": {
"version": "0.2.1",
"resolved": "https://registry.npmjs.org/tmp/-/tmp-0.2.1.tgz",
"integrity": "sha512-76SUhtfqR2Ijn+xllcI5P1oyannHNHByD80W1q447gU3mp9G9PSpGdWmjUOHRDPiHYacIk66W7ubDTuPF3BEtQ==",
"dev": true,
"dependencies": {
"rimraf": "^3.0.0"
},
"engines": {
"node": ">=8.17.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/to-through": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/to-through/-/to-through-3.0.0.tgz",
"integrity": "sha512-y8MN937s/HVhEoBU1SxfHC+wxCHkV1a9gW8eAdTadYh/bGyesZIVcbjI+mSpFbSVwQici/XjBjuUyri1dnXwBw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"streamx": "^2.12.5"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"node_modules/toml-eslint-parser": {
Update npm packages
2024-03-17 13:50:21 +01:00
"version": "0.9.3",
"resolved": "https://registry.npmjs.org/toml-eslint-parser/-/toml-eslint-parser-0.9.3.tgz",
"integrity": "sha512-moYoCvkNUAPCxSW9jmHmRElhm4tVJpHL8ItC/+uYD0EpPSFXbck7yREz9tNdJVTSpHVod8+HoipcpbQ0oE6gsw==",
Update dependencies to the most recent versions
2023-11-25 17:25:35 +01:00
"dev": true,
"dependencies": {
"eslint-visitor-keys": "^3.0.0"
},
"engines": {
"node": "^12.22.0 || ^14.17.0 || >=16.0.0"
},
"funding": {
"url": "https://github.com/sponsors/ota-meshi"
}
},
Upgrade to Puppeteer 12
2021-11-28 19:22:52 +01:00
"node_modules/tr46": {
"version": "0.0.3",
"resolved": "https://registry.npmjs.org/tr46/-/tr46-0.0.3.tgz",
"integrity": "sha1-gYT9NH2snNwYWZLzpmIuFLnZq2o=",
"dev": true
},
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"node_modules/tsc-alias": {
Update dependencies to the most recent versions The Puppeteer update should in particular be helpful for us because it contains improved WebDriver BiDi compatibility, a newer Chrome version (both might help for #17962) and an official deprecation of CDP for Firefox. Note that the latter doesn't require changes on our end because we already use WebDriver BiDi unconditionally for Firefox since commit 4db0174. The full release notes can be found at https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v22.8.0.
2024-05-14 16:19:34 +02:00
"version": "1.8.10",
"resolved": "https://registry.npmjs.org/tsc-alias/-/tsc-alias-1.8.10.tgz",
"integrity": "sha512-Ibv4KAWfFkFdKJxnWfVtdOmB0Zi1RJVxcbPGiCDsFpCQSsmpWyuzHG3rQyI5YkobWwxFPEyQfu1hdo4qLG2zPw==",
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"dev": true,
"dependencies": {
"chokidar": "^3.5.3",
"commander": "^9.0.0",
"globby": "^11.0.4",
"mylas": "^2.1.9",
"normalize-path": "^3.0.0",
"plimit-lit": "^1.2.6"
},
"bin": {
"tsc-alias": "dist/bin/index.js"
}
},
"node_modules/tsc-alias/node_modules/anymatch": {
"version": "3.1.3",
"resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.3.tgz",
"integrity": "sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==",
"dev": true,
"dependencies": {
"normalize-path": "^3.0.0",
"picomatch": "^2.0.4"
},
"engines": {
"node": ">= 8"
}
},
"node_modules/tsc-alias/node_modules/binary-extensions": {
"version": "2.2.0",
"resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.2.0.tgz",
"integrity": "sha512-jDctJ/IVQbZoJykoeHbhXpOlNBqGNcwXJKJog42E5HDPUwQTSdjCHdihjj0DlnheQ7blbT6dHOafNAiS8ooQKA==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/tsc-alias/node_modules/braces": {
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"version": "3.0.3",
"resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
"integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"dependencies": {
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"fill-range": "^7.1.1"
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
},
"engines": {
"node": ">=8"
}
},
"node_modules/tsc-alias/node_modules/chokidar": {
"version": "3.5.3",
"resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.5.3.tgz",
"integrity": "sha512-Dr3sfKRP6oTcjf2JmUmFJfeVMvXBdegxB0iVQ5eb2V10uFJUCAS8OByZdVAyVb8xXNz3GjjTgj9kLWsZTqE6kw==",
"dev": true,
"funding": [
{
"type": "individual",
"url": "https://paulmillr.com/funding/"
}
],
"dependencies": {
"anymatch": "~3.1.2",
"braces": "~3.0.2",
"glob-parent": "~5.1.2",
"is-binary-path": "~2.1.0",
"is-glob": "~4.0.1",
"normalize-path": "~3.0.0",
"readdirp": "~3.6.0"
},
"engines": {
"node": ">= 8.10.0"
},
"optionalDependencies": {
"fsevents": "~2.3.2"
}
},
"node_modules/tsc-alias/node_modules/commander": {
"version": "9.5.0",
"resolved": "https://registry.npmjs.org/commander/-/commander-9.5.0.tgz",
"integrity": "sha512-KRs7WVDKg86PWiuAqhDrAQnTXZKraVcCc6vFdL14qrZ/DcWwuRo7VoiYXalXO7S5GKpqYiVEwCbgFDfxNHKJBQ==",
"dev": true,
"engines": {
"node": "^12.20.0 || >=14"
}
},
"node_modules/tsc-alias/node_modules/fill-range": {
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"version": "7.1.1",
"resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
"integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"dependencies": {
"to-regex-range": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/tsc-alias/node_modules/glob-parent": {
"version": "5.1.2",
"resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz",
"integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==",
"dev": true,
"dependencies": {
"is-glob": "^4.0.1"
},
"engines": {
"node": ">= 6"
}
},
"node_modules/tsc-alias/node_modules/is-binary-path": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz",
"integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==",
"dev": true,
"dependencies": {
"binary-extensions": "^2.0.0"
},
"engines": {
"node": ">=8"
}
},
"node_modules/tsc-alias/node_modules/is-glob": {
"version": "4.0.3",
"resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz",
"integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==",
"dev": true,
"dependencies": {
"is-extglob": "^2.1.1"
},
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/tsc-alias/node_modules/is-number": {
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
"integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==",
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"engines": {
"node": ">=0.12.0"
}
},
"node_modules/tsc-alias/node_modules/normalize-path": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz",
"integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/tsc-alias/node_modules/readdirp": {
"version": "3.6.0",
"resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.6.0.tgz",
"integrity": "sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==",
"dev": true,
"dependencies": {
"picomatch": "^2.2.1"
},
"engines": {
"node": ">=8.10.0"
}
},
"node_modules/tsc-alias/node_modules/to-regex-range": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
"integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
"dev": true,
Fix vulnerabilities in dependency versions This patch is generated automatically using `npm audit fix`.
2024-06-11 15:11:07 +02:00
"license": "MIT",
Add support for the import map in the type generator The typescript compiler is now configured to know about the import map to be able to resolve those imports and find the associated types. As tsc outputs declaration files using the original module identifiers and not the resolved ones, tsc-alias is used to post-process the declaration files by resolving those paths.
2023-08-31 12:59:27 +02:00
"dependencies": {
"is-number": "^7.0.0"
},
"engines": {
"node": ">=8.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/tsconfig-paths": {
Update npm packages
2023-12-23 12:29:51 +01:00
"version": "3.15.0",
"resolved": "https://registry.npmjs.org/tsconfig-paths/-/tsconfig-paths-3.15.0.tgz",
"integrity": "sha512-2Ac2RgzDe/cn48GvOe3M+o82pEFewD3UPbyoUHHdKasHwJKjds4fLXWf/Ux5kATBKN20oaFGu+jbElp1pos0mg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"@types/json5": "^0.0.29",
Update npm packages
2023-08-06 09:22:20 +02:00
"json5": "^1.0.2",
Update npm packages
2022-04-17 10:15:10 +02:00
"minimist": "^1.2.6",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"strip-bom": "^3.0.0"
}
},
"node_modules/tsconfig-paths/node_modules/json5": {
Bump json5 from 1.0.1 to 1.0.2 Bumps [json5](https://github.com/json5/json5) from 1.0.1 to 1.0.2. - [Release notes](https://github.com/json5/json5/releases) - [Changelog](https://github.com/json5/json5/blob/main/CHANGELOG.md) - [Commits](https://github.com/json5/json5/compare/v1.0.1...v1.0.2) --- updated-dependencies: - dependency-name: json5 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
2023-01-08 06:05:38 +00:00
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/json5/-/json5-1.0.2.tgz",
"integrity": "sha512-g1MWMLBiz8FKi1e4w0UyVL3w+iJceWAFBAaBnnGKOpNa5f8TLktkbre1+s6oICydWAm+HRUGTmI+//xv2hvXYA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"minimist": "^1.2.0"
},
"bin": {
"json5": "lib/cli.js"
}
},
"node_modules/tsconfig-paths/node_modules/strip-bom": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/strip-bom/-/strip-bom-3.0.0.tgz",
Update npm packages
2023-08-06 09:22:20 +02:00
"integrity": "sha512-vavAMRXOgBVNF6nyEEmL3DBK19iRpDcoIwW+swQ+CbGiu7lju6t+JklA1MHweoWtadgt4ISVUsXLyDq34ddcwA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=4"
}
},
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"node_modules/tslib": {
Update npm packages
2024-01-06 10:09:12 +01:00
"version": "2.6.2",
"resolved": "https://registry.npmjs.org/tslib/-/tslib-2.6.2.tgz",
"integrity": "sha512-AEYxH93jGFPn/a2iVAwW87VuUIkR1FVUKB77NwMF7nBTDkDrrT/Hpt/IrCJ0QXhW27jTBDcf5ZY7w6RiqTMw2Q==",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"dev": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/ttest": {
Update dependencies to the most recent versions
2022-04-02 16:19:17 +02:00
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/ttest/-/ttest-4.0.0.tgz",
"integrity": "sha512-biXJWXntqllqzhEPN0TlpwSp4d2xjY2VblchlkJaLIAmlvny9bhpiiPNAlrjyQxcJC1ehoqB8w6JD2WU2p+yUQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"distributions": "^2.1.0",
"summary": "^2.0.0"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/tunnel-agent": {
"version": "0.6.0",
"resolved": "https://registry.npmjs.org/tunnel-agent/-/tunnel-agent-0.6.0.tgz",
"integrity": "sha512-McnNiV1l8RYeY8tBgEpuodCC1mLUdbSN+CYBL7kJsJNInOP8UjDDEwdk6Mw60vdLLrr5NHKZhMAOSrR2NZuQ+w==",
"dev": true,
"dependencies": {
"safe-buffer": "^5.0.1"
},
"engines": {
"node": "*"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/type-fest": {
"version": "0.8.1",
"resolved": "https://registry.npmjs.org/type-fest/-/type-fest-0.8.1.tgz",
"integrity": "sha512-4dbzIzqvjtgiM5rw1k5rEHtBANKmdudhGyBEajN01fEyhaAIhsoKNy6y7+IN93IfpFtwY9iqi7kD+xwKhQsNJA==",
"dev": true,
"engines": {
"node": ">=8"
}
},
Update npm packages
2023-08-06 09:22:20 +02:00
"node_modules/typed-array-buffer": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/typed-array-buffer/-/typed-array-buffer-1.0.0.tgz",
"integrity": "sha512-Y8KTSIglk9OZEr8zywiIHG/kmQ7KWyjseXs1CbSo8vC42w7hg2HgYTxSWwP0+is7bWDc1H+Fo026CpHFwm8tkw==",
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
"get-intrinsic": "^1.2.1",
"is-typed-array": "^1.1.10"
},
"engines": {
"node": ">= 0.4"
}
},
"node_modules/typed-array-byte-length": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/typed-array-byte-length/-/typed-array-byte-length-1.0.0.tgz",
"integrity": "sha512-Or/+kvLxNpeQ9DtSydonMxCx+9ZXOswtwJn17SNLvhptaXYDJvkFFP5zbfU/uLmvnBJlI4yrnXRxpdWH/M5tNA==",
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
"for-each": "^0.3.3",
"has-proto": "^1.0.1",
"is-typed-array": "^1.1.10"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/typed-array-byte-offset": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/typed-array-byte-offset/-/typed-array-byte-offset-1.0.0.tgz",
"integrity": "sha512-RD97prjEt9EL8YgAgpOkf3O4IF9lhJFr9g0htQkm0rchFp/Vx7LW5Q8fSXXub7BXAODyUQohRMyOc3faCPd0hg==",
"dev": true,
"dependencies": {
"available-typed-arrays": "^1.0.5",
"call-bind": "^1.0.2",
"for-each": "^0.3.3",
"has-proto": "^1.0.1",
"is-typed-array": "^1.1.10"
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Update npm packages
2023-01-15 10:34:56 +01:00
"node_modules/typed-array-length": {
"version": "1.0.4",
"resolved": "https://registry.npmjs.org/typed-array-length/-/typed-array-length-1.0.4.tgz",
"integrity": "sha512-KjZypGq+I/H7HI5HlOoGHkWUUGq+Q0TPhQurLbyrVrvnKTBgzLhIJ7j6J/XTQOi0d1RjyZ0wdas8bKs2p0x3Ng==",
"dev": true,
"dependencies": {
"call-bind": "^1.0.2",
"for-each": "^0.3.3",
"is-typed-array": "^1.1.9"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/typescript": {
Update dependencies to the most recent versions
2024-07-02 18:20:49 +02:00
"version": "5.5.3",
"resolved": "https://registry.npmjs.org/typescript/-/typescript-5.5.3.tgz",
"integrity": "sha512-/hreyEujaB0w76zKo6717l3L0o/qEUtRgdvUBvlkhoWeOVMjMuHNHk0BRBzikzuGDqNmPQbg5ifMEqsHLiIUcQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-06-21 17:09:21 +02:00
"license": "Apache-2.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"bin": {
"tsc": "bin/tsc",
"tsserver": "bin/tsserver"
},
"engines": {
Update npm packages
2023-06-11 11:30:39 +02:00
"node": ">=14.17"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/uc.micro": {
"version": "1.0.5",
"resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-1.0.5.tgz",
"integrity": "sha512-JoLI4g5zv5qNyT09f4YAvEZIIV1oOjqnewYg5D38dkQljIzpPT296dbIGvKro3digYI1bkb7W6EP1y4uDlmzLg==",
"dev": true,
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"peer": true
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"node_modules/unbox-primitive": {
Update npm packages
2022-09-18 10:31:32 +02:00
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/unbox-primitive/-/unbox-primitive-1.0.2.tgz",
"integrity": "sha512-61pPlCD9h51VoreyJ0BReideM3MDKMKnh6+V9L08331ipq6Q8OFXZYiqP6n/tbHx4s5I9uRhcye6BrbkizkBDw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update npm packages
2022-09-18 10:31:32 +02:00
"call-bind": "^1.0.2",
"has-bigints": "^1.0.2",
"has-symbols": "^1.0.3",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"which-boxed-primitive": "^1.0.2"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
"node_modules/unbzip2-stream": {
Upgrade to Puppeteer 12
2021-11-28 19:22:52 +01:00
"version": "1.4.3",
"resolved": "https://registry.npmjs.org/unbzip2-stream/-/unbzip2-stream-1.4.3.tgz",
"integrity": "sha512-mlExGW4w71ebDJviH16lQLtZS32VKqsSfk80GCfUlwT/4/hNRFsoscrF/c++9xinkMzECL1uL9DDwXqFWkruPg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"buffer": "^5.2.1",
"through": "^2.3.8"
}
},
"node_modules/unc-path-regex": {
"version": "0.1.2",
"resolved": "https://registry.npmjs.org/unc-path-regex/-/unc-path-regex-0.1.2.tgz",
"integrity": "sha1-5z3T17DXxe2G+6xrCufYxqadUPo=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/underscore": {
Update npm packages
2022-01-23 10:58:15 +01:00
"version": "1.13.2",
"resolved": "https://registry.npmjs.org/underscore/-/underscore-1.13.2.tgz",
"integrity": "sha512-ekY1NhRzq0B08g4bGuX4wd2jZx5GnKz6mKSqFL4nqBlfyMGiG10gDFhDTMEfYmDL6Jy0FUIZp7wiRB+0BP7J2g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
"node_modules/undertaker": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/undertaker/-/undertaker-2.0.0.tgz",
"integrity": "sha512-tO/bf30wBbTsJ7go80j0RzA2rcwX6o7XPBpeFcb+jzoeb4pfMM2zUeSDIkY1AWqeZabWxaQZ/h8N9t35QKDLPQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"bach": "^2.0.1",
"fast-levenshtein": "^3.0.0",
"last-run": "^2.0.0",
"undertaker-registry": "^2.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/undertaker-registry": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/undertaker-registry/-/undertaker-registry-2.0.0.tgz",
"integrity": "sha512-+hhVICbnp+rlzZMgxXenpvTxpuvA67Bfgtt+O9WOE5jo7w/dyiF1VmoZVIHvP2EkUjsyKyTwYKlLhA+j47m1Ew==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">= 10.13.0"
}
},
"node_modules/undertaker/node_modules/fast-levenshtein": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/fast-levenshtein/-/fast-levenshtein-3.0.0.tgz",
"integrity": "sha512-hKKNajm46uNmTlhHSyZkmToAc56uZJwYq7yrciZjqOxnlfQwERDQJmHPUp7m1m9wx8vgOe8IaCKZ5Kv2k1DdCQ==",
"dev": true,
"license": "MIT",
"dependencies": {
"fastest-levenshtein": "^1.0.7"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update npm packages
2022-01-09 10:05:52 +01:00
"node_modules/unicode-canonical-property-names-ecmascript": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/unicode-canonical-property-names-ecmascript/-/unicode-canonical-property-names-ecmascript-2.0.0.tgz",
"integrity": "sha512-yY5PpDlfVIU5+y/BSCxAJRBIS1Zc2dDG3Ujq+sR0U+JjUevW2JhocOF+soROYDSaAezOzOKuyyixhD6mBknSmQ==",
"dev": true,
"engines": {
"node": ">=4"
}
},
"node_modules/unicode-match-property-ecmascript": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/unicode-match-property-ecmascript/-/unicode-match-property-ecmascript-2.0.0.tgz",
"integrity": "sha512-5kaZCrbp5mmbz5ulBkDkbY0SsPOjKqVS35VpL9ulMPfSl0J0Xsm+9Evphv9CoIZFwre7aJoa94AY6seMKGVN5Q==",
"dev": true,
"dependencies": {
"unicode-canonical-property-names-ecmascript": "^2.0.0",
"unicode-property-aliases-ecmascript": "^2.0.0"
},
"engines": {
"node": ">=4"
}
},
"node_modules/unicode-match-property-value-ecmascript": {
Update npm packages
2023-04-15 22:08:58 +02:00
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/unicode-match-property-value-ecmascript/-/unicode-match-property-value-ecmascript-2.1.0.tgz",
"integrity": "sha512-qxkjQt6qjg/mYscYMC0XKRn3Rh0wFPlfxB0xkt9CfyTvpX1Ra0+rAmdX2QyAobptSEvuy4RtpPRui6XkV+8wjA==",
Update npm packages
2022-01-09 10:05:52 +01:00
"dev": true,
"engines": {
"node": ">=4"
}
},
"node_modules/unicode-property-aliases-ecmascript": {
Update npm packages
2023-04-15 22:08:58 +02:00
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/unicode-property-aliases-ecmascript/-/unicode-property-aliases-ecmascript-2.1.0.tgz",
"integrity": "sha512-6t3foTQI9qne+OZoVQB/8x8rk2k1eVy1gRXhV3oFQ5T6R1dqQ1xtin3XqSlx3+ATBkliTaR/hHyJBm+LVPNM8w==",
Update npm packages
2022-01-09 10:05:52 +01:00
"dev": true,
"engines": {
"node": ">=4"
}
},
Update npm packages
2023-07-23 09:49:53 +02:00
"node_modules/universalify": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/universalify/-/universalify-2.0.1.tgz",
"integrity": "sha512-gptHNQghINnc/vTGIk0SOFGFNXw7JVrlRUtConJRlvaw6DuX0wO5Jeko9sWrMBhh+PsYAZ7oXAiOnf/UKogyiw==",
Update npm packages
2023-07-23 09:49:53 +02:00
"dev": true,
"engines": {
Update puppeteer to 22.3.0
2024-02-27 10:16:12 +01:00
"node": ">= 10.0.0"
Update npm packages
2023-07-23 09:49:53 +02:00
}
},
Update npm packages
2022-07-10 10:43:08 +02:00
"node_modules/update-browserslist-db": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/update-browserslist-db/-/update-browserslist-db-1.1.0.tgz",
"integrity": "sha512-EdRAaAyk2cUE1wOf2DkEhzxqOQvFOoRJFNS6NeyJ01Gp2beMRpBAINjM2iDXE3KCuKhwnvHIQCJm6ThL2Z+HzQ==",
Update npm packages
2022-07-10 10:43:08 +02:00
"dev": true,
"funding": [
{
"type": "opencollective",
"url": "https://opencollective.com/browserslist"
},
{
"type": "tidelift",
"url": "https://tidelift.com/funding/github/npm/browserslist"
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
},
{
"type": "github",
"url": "https://github.com/sponsors/ai"
Update npm packages
2022-07-10 10:43:08 +02:00
}
],
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"license": "MIT",
Update npm packages
2022-07-10 10:43:08 +02:00
"dependencies": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"escalade": "^3.1.2",
"picocolors": "^1.0.1"
Update npm packages
2022-07-10 10:43:08 +02:00
},
"bin": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"update-browserslist-db": "cli.js"
Update npm packages
2022-07-10 10:43:08 +02:00
},
"peerDependencies": {
"browserslist": ">= 4.21.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/uri-js": {
"version": "4.2.2",
"resolved": "https://registry.npmjs.org/uri-js/-/uri-js-4.2.2.tgz",
"integrity": "sha512-KY9Frmirql91X2Qgjry0Wd4Y+YTdrdZheS8TFwvkbLWf/G5KNJDCh6pKL5OZctEW4+0Baa5idK2ZQuELRwPznQ==",
"dev": true,
"dependencies": {
"punycode": "^2.1.0"
}
},
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"node_modules/url-join": {
"version": "4.0.1",
"resolved": "https://registry.npmjs.org/url-join/-/url-join-4.0.1.tgz",
"integrity": "sha512-jk1+QP6ZJqyOiuEI9AEWQfju/nB2Pw466kbA0LEZljHwKeMgd9WrAEgEGxjPDD2+TNbbb37rTyhEfrCXfuKXnA==",
"dev": true
},
Update Puppeteer to the latest version This also required updating the `postinstall`-step to account for recent changes in Puppeteer.
2023-09-25 11:56:02 +02:00
"node_modules/urlpattern-polyfill": {
Update dependencies to the most recent versions
2024-02-10 18:02:15 +01:00
"version": "10.0.0",
"resolved": "https://registry.npmjs.org/urlpattern-polyfill/-/urlpattern-polyfill-10.0.0.tgz",
"integrity": "sha512-H/A06tKD7sS1O1X2SshBVeA5FLycRpjqiBeqGKmBwBDBy28EnRjORxTNe269KSSr5un5qyWi1iL61wLxpd+ZOg==",
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"dev": true,
"license": "MIT"
Update Puppeteer to the latest version This also required updating the `postinstall`-step to account for recent changes in Puppeteer.
2023-09-25 11:56:02 +02:00
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/util-deprecate": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz",
"integrity": "sha1-RQ1Nyfpw3nMnYvvS1KKJgUGaDM8=",
"dev": true
},
"node_modules/v8flags": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "4.0.1",
"resolved": "https://registry.npmjs.org/v8flags/-/v8flags-4.0.1.tgz",
"integrity": "sha512-fcRLaS4H/hrZk9hYwbdRM35D0U8IYMfEClhXxCivOojl+yTRAZH3Zy2sSy6qVCiGbV9YAtPssP6jaChqC9vPCg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/validate-npm-package-license": {
"version": "3.0.3",
"resolved": "https://registry.npmjs.org/validate-npm-package-license/-/validate-npm-package-license-3.0.3.tgz",
"integrity": "sha512-63ZOUnL4SIXj4L0NixR3L1lcjO38crAbgrTpl28t8jjrfuiOBL5Iygm+60qPs/KsZGzPNg6Smnc/oY16QTjF0g==",
"dev": true,
"dependencies": {
"spdx-correct": "^3.0.0",
"spdx-expression-parse": "^3.0.0"
}
},
"node_modules/value-or-function": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/value-or-function/-/value-or-function-4.0.0.tgz",
"integrity": "sha512-aeVK81SIuT6aMJfNo9Vte8Dw0/FZINGBV8BfCraGtqVxIeLAEhJyoWs8SmvRVmXfGss2PmmOwZCuBPbZR+IYWg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">= 10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/vinyl": {
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/vinyl/-/vinyl-3.0.0.tgz",
"integrity": "sha512-rC2VRfAVVCGEgjnxHUnpIVh3AGuk62rP3tqVrn+yab0YH7UULisC085+NYH+mnqf3Wx4SpSi1RQMwudL89N03g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"clone": "^2.1.2",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"clone-stats": "^1.0.0",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"remove-trailing-separator": "^1.1.0",
"replace-ext": "^2.0.0",
"teex": "^1.0.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"node": ">=10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/vinyl-contents": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/vinyl-contents/-/vinyl-contents-2.0.0.tgz",
"integrity": "sha512-cHq6NnGyi2pZ7xwdHSW1v4Jfnho4TEGtxZHw01cmnc8+i7jgR6bRnED/LbrKan/Q7CvVLbnvA5OepnhbpjBZ5Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"bl": "^5.0.0",
"vinyl": "^3.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/vinyl-contents/node_modules/bl": {
"version": "5.1.0",
"resolved": "https://registry.npmjs.org/bl/-/bl-5.1.0.tgz",
"integrity": "sha512-tv1ZJHLfTDnXE6tMHv73YgSJaWR2AFuPwMntBe7XL/GBFHnT0CLnsHMogfk5+GzCDC5ZWarSCYaIGATZt9dNsQ==",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
"dependencies": {
"buffer": "^6.0.3",
"inherits": "^2.0.4",
"readable-stream": "^3.4.0"
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/vinyl-contents/node_modules/buffer": {
"version": "6.0.3",
"resolved": "https://registry.npmjs.org/buffer/-/buffer-6.0.3.tgz",
"integrity": "sha512-FTiCpNxtwiZZHEZbcbTIcZjERVICn9yq/pDFkTl95/AxzD1naBctN7YO68riM/gLSDY7sdrMby8hofADYuuqOA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"funding": [
{
"type": "github",
"url": "https://github.com/sponsors/feross"
},
{
"type": "patreon",
"url": "https://www.patreon.com/feross"
},
{
"type": "consulting",
"url": "https://feross.org/support"
}
],
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"base64-js": "^1.3.1",
"ieee754": "^1.2.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/vinyl-contents/node_modules/readable-stream": {
"version": "3.6.2",
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.2.tgz",
"integrity": "sha512-9u/sniCrY3D5WdsERHzHE4G2YCXqoG5FTHUiCC4SIbr6XcLZBY05ya9EKjYek9O5xOAwjGq+1JdGBAS7Q9ScoA==",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"inherits": "^2.0.3",
"string_decoder": "^1.1.1",
"util-deprecate": "^1.0.1"
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">= 6"
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/vinyl-fs": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/vinyl-fs/-/vinyl-fs-4.0.0.tgz",
"integrity": "sha512-7GbgBnYfaquMk3Qu9g22x000vbYkOex32930rBnc3qByw6HfMEAoELjCjoJv4HuEQxHAurT+nvMHm6MnJllFLw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"fs-mkdirp-stream": "^2.0.1",
"glob-stream": "^8.0.0",
"graceful-fs": "^4.2.11",
"iconv-lite": "^0.6.3",
"is-valid-glob": "^1.0.0",
"lead": "^4.0.0",
"normalize-path": "3.0.0",
"resolve-options": "^2.0.0",
"stream-composer": "^1.0.2",
"streamx": "^2.14.0",
"to-through": "^3.0.0",
"value-or-function": "^4.0.0",
"vinyl": "^3.0.0",
"vinyl-sourcemap": "^2.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/vinyl-fs/node_modules/normalize-path": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz",
"integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=0.10.0"
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
}
},
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node_modules/vinyl-sourcemap": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/vinyl-sourcemap/-/vinyl-sourcemap-2.0.0.tgz",
"integrity": "sha512-BAEvWxbBUXvlNoFQVFVHpybBbjW1r03WhohJzJDSfgrrK5xVYIDTan6xN14DlyImShgDRv2gl9qhM6irVMsV0Q==",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"dev": true,
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"license": "MIT",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"dependencies": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"convert-source-map": "^2.0.0",
"graceful-fs": "^4.2.10",
"now-and-later": "^3.0.0",
"streamx": "^2.12.5",
"vinyl": "^3.0.0",
"vinyl-contents": "^2.0.0"
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
},
"engines": {
Upgrade `gulp` to version 5.0.0 This is a major version bump, and the changelog at https://github.com/gulpjs/gulp/releases/tag/v5.0.0 indicates one breaking change that impacts us, namely that streams are now by default interpreted/transformed to UTF-8 encoding. This breaks `gulp.src` calls that work on binary files such as images or CMaps, but is fortunately easy to fix for us by disabling re-encoding for all `gulp.src` calls (see https://github.com/gulpjs/gulp/issues/2764#issuecomment-2063415792 for more information). This restores the previous behavior of copying the files as-is without Gulp performing any transformations to it, which is what we want because Gulp is only used for bundling and we make sure that the source files have the right encoding.
2024-05-30 15:55:23 +02:00
"node": ">=10.13.0"
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/vinyl-sourcemaps-apply": {
"version": "0.2.1",
"resolved": "https://registry.npmjs.org/vinyl-sourcemaps-apply/-/vinyl-sourcemaps-apply-0.2.1.tgz",
"integrity": "sha1-q2VJ1h0XLCsbh75cUI0jnI74dwU=",
"dev": true,
"dependencies": {
"source-map": "^0.5.1"
}
},
"node_modules/vinyl-sourcemaps-apply/node_modules/source-map": {
"version": "0.5.7",
"resolved": "https://registry.npmjs.org/source-map/-/source-map-0.5.7.tgz",
"integrity": "sha1-igOdLRAh0i0eoUyA2OpGi6LvP8w=",
"dev": true,
"engines": {
"node": ">=0.10.0"
}
},
"node_modules/vscode-json-languageservice": {
"version": "4.1.6",
"resolved": "https://registry.npmjs.org/vscode-json-languageservice/-/vscode-json-languageservice-4.1.6.tgz",
"integrity": "sha512-DIKb3tcfRtb3tIE6g9SLOl5E9tNSt6kljH08Wa5RwFlVshtXGrDDzttchze4CYy9pJpE9mBtCbRHmLvY1Z1ZXA==",
"dev": true,
"dependencies": {
"jsonc-parser": "^3.0.0",
"vscode-languageserver-textdocument": "^1.0.1",
"vscode-languageserver-types": "^3.16.0",
"vscode-nls": "^5.0.0",
"vscode-uri": "^3.0.2"
},
"engines": {
"npm": ">=7.0.0"
}
},
"node_modules/vscode-languageserver-textdocument": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/vscode-languageserver-textdocument/-/vscode-languageserver-textdocument-1.0.1.tgz",
"integrity": "sha512-UIcJDjX7IFkck7cSkNNyzIz5FyvpQfY7sdzVy+wkKN/BLaD4DQ0ppXQrKePomCxTS7RrolK1I0pey0bG9eh8dA==",
"dev": true
},
"node_modules/vscode-languageserver-types": {
"version": "3.16.0",
"resolved": "https://registry.npmjs.org/vscode-languageserver-types/-/vscode-languageserver-types-3.16.0.tgz",
"integrity": "sha512-k8luDIWJWyenLc5ToFQQMaSrqCHiLwyKPHKPQZ5zz21vM+vIVUSvsRpcbiECH4WR88K2XZqc4ScRcZ7nk/jbeA==",
"dev": true
},
"node_modules/vscode-nls": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/vscode-nls/-/vscode-nls-5.0.0.tgz",
"integrity": "sha512-u0Lw+IYlgbEJFF6/qAqG2d1jQmJl0eyAGJHoAJqr2HT4M2BNuQYSEiSE75f52pXHSJm8AlTjnLLbBFPrdz2hpA==",
"dev": true
},
"node_modules/vscode-uri": {
"version": "3.0.2",
"resolved": "https://registry.npmjs.org/vscode-uri/-/vscode-uri-3.0.2.tgz",
"integrity": "sha512-jkjy6pjU1fxUvI51P+gCsxg1u2n8LSt0W6KrCNQceaziKzff74GoWmjVG46KieVzybO1sttPQmYfrwSHey7GUA==",
"dev": true
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/ware": {
"version": "1.3.0",
"resolved": "https://registry.npmjs.org/ware/-/ware-1.3.0.tgz",
"integrity": "sha512-Y2HUDMktriUm+SR2gZWxlrszcgtXExlhQYZ8QJNYbl22jum00KIUcHJ/h/sdAXhWTJcbSkiMYN9Z2tWbWYSrrw==",
"dev": true,
"license": "MIT",
"dependencies": {
"wrap-fn": "^0.1.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/watchpack": {
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"version": "2.4.1",
"resolved": "https://registry.npmjs.org/watchpack/-/watchpack-2.4.1.tgz",
"integrity": "sha512-8wrBCMtVhqcXP2Sup1ctSkga6uc2Bx0IIvKyT7yTFier5AXHooSI+QyQQAtTb7+E0IUCCKyTFmXqdqgum2XWGg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"glob-to-regexp": "^0.4.1",
"graceful-fs": "^4.1.2"
},
"engines": {
"node": ">=10.13.0"
}
},
Upgrade to Puppeteer 12
2021-11-28 19:22:52 +01:00
"node_modules/webidl-conversions": {
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/webidl-conversions/-/webidl-conversions-3.0.1.tgz",
"integrity": "sha1-JFNCdeKnvGvnvIZhHMFq4KVlSHE=",
"dev": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/webpack": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "5.93.0",
"resolved": "https://registry.npmjs.org/webpack/-/webpack-5.93.0.tgz",
"integrity": "sha512-Y0m5oEY1LRuwly578VqluorkXbvXKh7U3rLoQCEO04M97ScRr44afGVkI0FQFsXzysk5OgFAxjZAb9rsGQVihA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
Update npm packages
2022-02-20 10:08:23 +01:00
"@types/eslint-scope": "^3.7.3",
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"@types/estree": "^1.0.5",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"@webassemblyjs/ast": "^1.12.1",
"@webassemblyjs/wasm-edit": "^1.12.1",
"@webassemblyjs/wasm-parser": "^1.12.1",
Update npm packages
2022-08-07 10:20:21 +02:00
"acorn": "^8.7.1",
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"acorn-import-attributes": "^1.9.5",
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"browserslist": "^4.21.10",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"chrome-trace-event": "^1.0.2",
Update dependencies to the most recent versions
2024-06-18 18:36:21 +02:00
"enhanced-resolve": "^5.17.0",
Update npm packages
2023-04-15 22:08:58 +02:00
"es-module-lexer": "^1.2.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"eslint-scope": "5.1.1",
"events": "^3.2.0",
"glob-to-regexp": "^0.4.1",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"graceful-fs": "^4.2.11",
Update npm packages
2022-05-15 09:02:57 +02:00
"json-parse-even-better-errors": "^2.3.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"loader-runner": "^4.2.0",
"mime-types": "^2.1.27",
"neo-async": "^2.6.2",
Update npm packages
2023-06-25 09:18:41 +02:00
"schema-utils": "^3.2.0",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"tapable": "^2.1.1",
Update dependencies to the most recent versions
2024-01-27 19:04:12 +01:00
"terser-webpack-plugin": "^5.3.10",
Update dependencies to the most recent versions
2024-03-26 16:25:41 +01:00
"watchpack": "^2.4.1",
Update npm packages
2022-01-23 10:58:15 +01:00
"webpack-sources": "^3.2.3"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"bin": {
"webpack": "bin/webpack.js"
},
"engines": {
"node": ">=10.13.0"
},
"funding": {
"type": "opencollective",
"url": "https://opencollective.com/webpack"
},
"peerDependenciesMeta": {
"webpack-cli": {
"optional": true
}
}
},
"node_modules/webpack-sources": {
Update npm packages
2022-01-23 10:58:15 +01:00
"version": "3.2.3",
"resolved": "https://registry.npmjs.org/webpack-sources/-/webpack-sources-3.2.3.tgz",
"integrity": "sha512-/DyMEOrDgLKKIG0fmvtz+4dUX/3Ghozwgm6iPp8KRhvn+eQf9+Q7GWxVNMk3+uCPWfdXYC4ExGBckIXdFEfH1w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
"node": ">=10.13.0"
}
},
"node_modules/webpack-stream": {
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/webpack-stream/-/webpack-stream-7.0.0.tgz",
"integrity": "sha512-XoAQTHyCaYMo6TS7Atv1HYhtmBgKiVLONJbzLBl2V3eibXQ2IT/MCRM841RW/r3vToKD5ivrTJFWgd/ghoxoRg==",
"dev": true,
"dependencies": {
"fancy-log": "^1.3.3",
"lodash.clone": "^4.3.2",
"lodash.some": "^4.2.2",
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"memory-fs": "^0.5.0",
"plugin-error": "^1.0.1",
"supports-color": "^8.1.1",
"through": "^2.3.8",
"vinyl": "^2.2.1"
},
"engines": {
"node": ">= 10.0.0"
},
"peerDependencies": {
"webpack": "^5.21.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"node_modules/webpack-stream/node_modules/has-flag": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz",
"integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"engines": {
"node": ">=8"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"node_modules/webpack-stream/node_modules/replace-ext": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/replace-ext/-/replace-ext-1.0.1.tgz",
"integrity": "sha512-yD5BHCe7quCgBph4rMQ+0KkIRKwWCrHDOX1p1Gp6HwjPM5kVoCdKGNhN7ydqqsX6lJEnQDKZ/tFMiEdQ1dvPEw==",
"dev": true,
"engines": {
"node": ">= 0.10"
}
},
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"node_modules/webpack-stream/node_modules/supports-color": {
"version": "8.1.1",
"resolved": "https://registry.npmjs.org/supports-color/-/supports-color-8.1.1.tgz",
"integrity": "sha512-MpUEN2OodtUzxvKQl72cUF7RQ5EiHsGvSsVG0ia9c5RbWGL2CI4C7EpPS8UTBIplnlzZiNuV56w+FuNxy3ty2Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"has-flag": "^4.0.0"
},
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/chalk/supports-color?sponsor=1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"node_modules/webpack-stream/node_modules/vinyl": {
"version": "2.2.1",
"resolved": "https://registry.npmjs.org/vinyl/-/vinyl-2.2.1.tgz",
"integrity": "sha512-LII3bXRFBZLlezoG5FfZVcXflZgWP/4dCwKtxd5ky9+LOtM4CS3bIRQsmR1KMnMW07jpE8fqR2lcxPZ+8sJIcw==",
"dev": true,
"dependencies": {
"clone": "^2.1.1",
"clone-buffer": "^1.0.0",
"clone-stats": "^1.0.0",
"cloneable-readable": "^1.0.0",
"remove-trailing-separator": "^1.0.1",
"replace-ext": "^1.0.0"
},
"engines": {
"node": ">= 0.10"
}
},
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"node_modules/webpack/node_modules/schema-utils": {
Update npm packages
2023-06-25 09:18:41 +02:00
"version": "3.3.0",
"resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-3.3.0.tgz",
"integrity": "sha512-pN/yOAvcC+5rQ5nERGuwrjLlYvLTbCibnZ1I7B1LaiAz9BRBlE9GMgE/eqV30P7aJQUf7Ddimy/RsbYO/GrVGg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"@types/json-schema": "^7.0.8",
"ajv": "^6.12.5",
"ajv-keywords": "^3.5.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"node": ">= 10.13.0"
},
"funding": {
"type": "opencollective",
"url": "https://opencollective.com/webpack"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"node_modules/whatwg-url": {
"version": "5.0.0",
"resolved": "https://registry.npmjs.org/whatwg-url/-/whatwg-url-5.0.0.tgz",
"integrity": "sha1-lmRU6HZUYuN2RNNib2dCzotwll0=",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"tr46": "~0.0.3",
"webidl-conversions": "^3.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"node_modules/which": {
"version": "1.3.1",
"resolved": "https://registry.npmjs.org/which/-/which-1.3.1.tgz",
"integrity": "sha512-HxJdYWq1MTIQbJ3nw0cqssHoTNU267KlrDuGZ1WYlxDStUtKUhOaJmh112/TZmHxxUfuJqPXSOm7tDyas0OSIQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"dependencies": {
"isexe": "^2.0.0"
},
"bin": {
"which": "bin/which"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"node_modules/which-boxed-primitive": {
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"version": "1.0.2",
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"resolved": "https://registry.npmjs.org/which-boxed-primitive/-/which-boxed-primitive-1.0.2.tgz",
"integrity": "sha512-bwZdv0AKLpplFY2KZRX6TvyuN7ojjr7lwkg6ml0roIy9YeuSr7JS372qlNW18UQYzgYK9ziGcerWqZOmEn9VNg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"dependencies": {
"is-bigint": "^1.0.1",
"is-boolean-object": "^1.1.0",
"is-number-object": "^1.0.4",
"is-string": "^1.0.5",
"is-symbol": "^1.0.3"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Update npm packages
2023-01-15 10:34:56 +01:00
"node_modules/which-typed-array": {
Update npm packages
2023-08-06 09:22:20 +02:00
"version": "1.1.11",
"resolved": "https://registry.npmjs.org/which-typed-array/-/which-typed-array-1.1.11.tgz",
"integrity": "sha512-qe9UWWpkeG5yzZ0tNYxDmd7vo58HDBc39mZ0xWWpolAGADdFOzkfamWLDxkOWcvHQKVmdTyQdLD4NOfjLWTKew==",
Update npm packages
2023-01-15 10:34:56 +01:00
"dev": true,
"dependencies": {
"available-typed-arrays": "^1.0.5",
"call-bind": "^1.0.2",
"for-each": "^0.3.3",
"gopd": "^1.0.1",
Update npm packages
2023-08-06 09:22:20 +02:00
"has-tostringtag": "^1.0.0"
Update npm packages
2023-01-15 10:34:56 +01:00
},
"engines": {
"node": ">= 0.4"
},
"funding": {
"url": "https://github.com/sponsors/ljharb"
}
},
Fix some dependency vulnerabilities reported by `npm audit` This is done automatically using the `npm audit fix` command.
2021-12-11 15:28:29 +01:00
"node_modules/wide-align": {
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"version": "1.1.5",
"resolved": "https://registry.npmjs.org/wide-align/-/wide-align-1.1.5.tgz",
"integrity": "sha512-eDMORYaPNZ4sQIuuYPDHdQvf4gyCF9rEEV/yPxGfwPkRodwEgiMUUXTx/dex+Me0wxx53S+NgUHaP7y3MGlDmg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
fuzz: initial integration - Adds initial fuzz_target for image decoders. - Adds jazzer.js as dev-dependency. - Adds a .eslintrc rule to ignore import/no-unresolved error.
2023-11-26 04:54:21 +05:30
"string-width": "^1.0.2 || 2 || 3 || 4"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/wrap-ansi": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz",
"integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"ansi-styles": "^4.0.0",
"string-width": "^4.1.0",
"strip-ansi": "^6.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node": ">=10"
},
"funding": {
"url": "https://github.com/chalk/wrap-ansi?sponsor=1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update `jasmine` to version 5 Despite this being a *major* version increase, it doesn't appear to require any updates in our test-suites. Note in particular that the minimum supported browsers/environments were updated, however this isn't a problem given our recent support-changes in the PDF.js library. Please find additional details at https://github.com/jasmine/jasmine/blob/main/release_notes/5.0.0.md
2023-05-14 12:57:31 +02:00
"node_modules/wrap-ansi-cjs": {
"name": "wrap-ansi",
"version": "7.0.0",
"resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz",
"integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==",
"dev": true,
"dependencies": {
"ansi-styles": "^4.0.0",
"string-width": "^4.1.0",
"strip-ansi": "^6.0.0"
},
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/chalk/wrap-ansi?sponsor=1"
}
},
"node_modules/wrap-ansi-cjs/node_modules/ansi-regex": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
"integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/wrap-ansi-cjs/node_modules/ansi-styles": {
"version": "4.3.0",
"resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz",
"integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==",
"dev": true,
"dependencies": {
"color-convert": "^2.0.1"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/chalk/ansi-styles?sponsor=1"
}
},
"node_modules/wrap-ansi-cjs/node_modules/color-convert": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz",
"integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==",
"dev": true,
"dependencies": {
"color-name": "~1.1.4"
},
"engines": {
"node": ">=7.0.0"
}
},
"node_modules/wrap-ansi-cjs/node_modules/is-fullwidth-code-point": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
"integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/wrap-ansi-cjs/node_modules/string-width": {
"version": "4.2.3",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
"integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
"dev": true,
"dependencies": {
"emoji-regex": "^8.0.0",
"is-fullwidth-code-point": "^3.0.0",
"strip-ansi": "^6.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/wrap-ansi-cjs/node_modules/strip-ansi": {
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
"integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
"dev": true,
"dependencies": {
"ansi-regex": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"node_modules/wrap-ansi/node_modules/ansi-regex": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
"integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/wrap-ansi/node_modules/ansi-styles": {
"version": "4.3.0",
"resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz",
"integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==",
"dev": true,
"dependencies": {
"color-convert": "^2.0.1"
},
"engines": {
"node": ">=8"
},
"funding": {
"url": "https://github.com/chalk/ansi-styles?sponsor=1"
}
},
"node_modules/wrap-ansi/node_modules/color-convert": {
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz",
"integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==",
"dev": true,
"dependencies": {
"color-name": "~1.1.4"
},
"engines": {
"node": ">=7.0.0"
}
},
"node_modules/wrap-ansi/node_modules/is-fullwidth-code-point": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
"integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/wrap-ansi/node_modules/string-width": {
"version": "4.2.3",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
"integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
"dev": true,
"dependencies": {
"emoji-regex": "^8.0.0",
"is-fullwidth-code-point": "^3.0.0",
"strip-ansi": "^6.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/wrap-ansi/node_modules/strip-ansi": {
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
"integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
"dev": true,
"dependencies": {
"ansi-regex": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
Replace Wintersmith with Metalsmith Wintersmith is no longer maintained given that the most recent version is from six years ago, and all vulnerabilities that NPM reports originate from Wintersmith's dependencies. Metalsmith, and its plugins, on the other hand have recently had releases and don't have known vulnerabilities. In fact, the number of reported vulnerabilities by NPM even goes down to zero with this patch applied. This commit therefore replaces Wintersmith with Metalsmith by providing a transparent drop-in replacement, in a way that requires the least amount of changes to the code and the generated output. Note that this patch does update our versions of jQuery, Bootstrap and the Highlight.js theme because the previous versions were very outdated and didn't work correctly with Metalsmith. Moreover, those old versions contained vulnerabilities that are hereby fixed. Fixes #18198.
2024-06-13 20:53:05 +02:00
"node_modules/wrap-fn": {
"version": "0.1.5",
"resolved": "https://registry.npmjs.org/wrap-fn/-/wrap-fn-0.1.5.tgz",
"integrity": "sha512-xDLdGx0M8JQw9QDAC9s5NUxtg9MI09F6Vbxa2LYoSoCvzJnx2n81YMIfykmXEGsUvuLaxnblJTzhSOjUOX37ag==",
"dev": true,
"license": "MIT",
"dependencies": {
"co": "3.1.0"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/wrappy": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz",
"integrity": "sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8=",
"dev": true
},
"node_modules/write-file-atomic": {
Update npm packages
2023-05-14 10:12:06 +02:00
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/write-file-atomic/-/write-file-atomic-5.0.1.tgz",
"integrity": "sha512-+QU2zd6OTD8XWIJCbffaiQeH9U73qIqafo1x6V1snCWYGJf6cVE0cDR4D8xRzcEnfI21IFrUPzPGtcPf8AC+Rw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"imurmurhash": "^0.1.4",
Update npm packages
2023-05-14 10:12:06 +02:00
"signal-exit": "^4.0.1"
Update npm packages
2022-02-06 11:24:14 +01:00
},
"engines": {
Update Stylelint to version 15 Notably this obsoletes the `stylelint-config-prettier` package; please see https://github.com/stylelint/stylelint/blob/main/docs/migration-guide/to-15.md for additional details.
2023-02-11 14:41:32 +01:00
"node": "^14.17.0 || ^16.13.0 || >=18.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
Update npm packages
2023-05-14 10:12:06 +02:00
"node_modules/write-file-atomic/node_modules/signal-exit": {
"version": "4.0.2",
"resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-4.0.2.tgz",
"integrity": "sha512-MY2/qGx4enyjprQnFaZsHib3Yadh3IXyV2C321GY0pjGfVBu4un0uDJkwgdxqO+Rdx8JMT8IfJIRwbYVz3Ob3Q==",
"dev": true,
"engines": {
"node": ">=14"
},
"funding": {
"url": "https://github.com/sponsors/isaacs"
}
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/ws": {
Update dependencies to the most recent versions
2024-07-13 16:06:32 +02:00
"version": "8.18.0",
"resolved": "https://registry.npmjs.org/ws/-/ws-8.18.0.tgz",
"integrity": "sha512-8VbfWfHLbbwu3+N6OKsOMpBdT4kXPDDB9cJk2bJ6mh9ucxdlnNvH1e+roYkKmN9Nxw2yjz7VzeO9oOz2zJ04Pw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"engines": {
Upgrade to Puppeteer 12
2021-11-28 19:22:52 +01:00
"node": ">=10.0.0"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependencies": {
"bufferutil": "^4.0.1",
Update Puppeteer to version 20 This commit makes the following required changes: - Replace custom cache trimming logic in favor of the (per our request) newly added `trimCache` method in Puppeteer. Not only does this greatly simplify our code and prevents having to import Puppeteer internals, it's also necessary because Puppeteer 20 removed the `BrowserFetcher` API in favor of the new separate `@puppeteer/browsers` package. - Start browsers in series instead of in parallel. Parallel browser starts broke since Puppetter 19.1.0 and it turns out that it has never been supported officially, so it worked more-or-less by accident. Starting browsers in series is the supported way, is almost equally fast and ensures that we avoid any race conditions during startup. Finally, it also allows us to remove the `browserPromise` state on our session objects. Fixes #15865.
2023-05-29 14:46:31 +02:00
"utf-8-validate": ">=5.0.2"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"peerDependenciesMeta": {
"bufferutil": {
"optional": true
},
"utf-8-validate": {
"optional": true
}
}
},
"node_modules/xmlcreate": {
Update npm packages
2022-01-23 10:58:15 +01:00
"version": "2.0.4",
"resolved": "https://registry.npmjs.org/xmlcreate/-/xmlcreate-2.0.4.tgz",
"integrity": "sha512-nquOebG4sngPmGPICTS5EnxqhKbCmz5Ox5hsszI2T6U5qdrJizBc+0ilYSEjTSzU0yZcmvppztXe/5Al5fUwdg==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true
},
"node_modules/y18n": {
Upgrade `gulp-cli` to version 3.0.0 This is a major version bump, but the changelog at https://github.com/gulpjs/gulp-cli/releases/tag/v3.0.0 doesn't indicate any breaking changes that should impact us.
2024-03-26 16:28:21 +01:00
"version": "5.0.8",
"resolved": "https://registry.npmjs.org/y18n/-/y18n-5.0.8.tgz",
"integrity": "sha512-0pfFzegeDWJHJIAmTLRP2DwHjdF5s7jo9tuztdQxAhINCdvS+3nGINqPd00AphqJR/0LhANUS6/+7SCb98YOfA==",
"dev": true,
"engines": {
"node": ">=10"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
Update npm packages
2022-12-25 12:26:23 +01:00
"node_modules/yallist": {
"version": "3.1.1",
"resolved": "https://registry.npmjs.org/yallist/-/yallist-3.1.1.tgz",
"integrity": "sha512-a4UGQaWPH59mOXUYnAG2ewncQS4i4F43Tv3JoAM+s2VDAmS9NsK8GpDMLrCHPksFT7h3K6TOoUNn2pb7RoXx4g==",
"dev": true
},
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"node_modules/yaml": {
Update npm packages
2024-01-20 09:40:33 +01:00
"version": "2.3.4",
"resolved": "https://registry.npmjs.org/yaml/-/yaml-2.3.4.tgz",
"integrity": "sha512-8aAvwVUSHpfEqTQ4w/KMlf3HcRdt50E5ODIQJBw1fQ5RL34xabzxtUlzTXVqc4rkZsPbvrXKWnABCD7kWSmocA==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Update npm packages
2024-01-20 09:40:33 +01:00
"node": ">= 14"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/yargs": {
Update npm packages
2023-05-14 10:12:06 +02:00
"version": "17.7.2",
"resolved": "https://registry.npmjs.org/yargs/-/yargs-17.7.2.tgz",
"integrity": "sha512-7dSzzRQ++CKnNI/krKnYRV7JKKPUXMEh61soaHKg9mrWEhzFWhFnxPxGl+69cD1Ou63C13NUPCnmIcrvqCuM6w==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"cliui": "^8.0.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"escalade": "^3.1.1",
"get-caller-file": "^2.0.5",
"require-directory": "^2.1.1",
Update packages to the most recent versions
2021-12-11 15:24:26 +01:00
"string-width": "^4.2.3",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"y18n": "^5.0.5",
Update npm packages
2022-11-13 21:28:21 +01:00
"yargs-parser": "^21.1.1"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
},
"engines": {
"node": ">=12"
}
},
"node_modules/yargs-parser": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"version": "21.1.1",
"resolved": "https://registry.npmjs.org/yargs-parser/-/yargs-parser-21.1.1.tgz",
"integrity": "sha512-tVpsJW7DdjecAiFpbIB1e3qxIQsE6NoPc5/eTdrbbIC4h0LVsWhnoa3g+m2HclBIujHzsxZ4VJVA+GUuc2/LBw==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"engines": {
Update npm packages Note that while some packages increased the *major* version, it doesn't appear to cause any breakage as far as I can tell.
2023-07-15 09:08:32 +02:00
"node": ">=12"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/yargs/node_modules/ansi-regex": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
"integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/yargs/node_modules/cliui": {
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"version": "8.0.1",
"resolved": "https://registry.npmjs.org/cliui/-/cliui-8.0.1.tgz",
"integrity": "sha512-BSeNnyus75C4//NQ9gQt1/csTXyo/8Sb+afLAkzAptFuMsod9HFokGNudZpi/oQV73hnVK+sR+5PVRMd+Dr7YQ==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
"dependencies": {
"string-width": "^4.2.0",
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
"strip-ansi": "^6.0.1",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"wrap-ansi": "^7.0.0"
Update dependencies to the most recent versions
2022-10-01 18:02:00 +02:00
},
"engines": {
"node": ">=12"
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
},
"node_modules/yargs/node_modules/is-fullwidth-code-point": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
"integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
"dev": true,
"engines": {
"node": ">=8"
}
},
"node_modules/yargs/node_modules/string-width": {
"version": "4.2.3",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
"integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
"dev": true,
"dependencies": {
"emoji-regex": "^8.0.0",
"is-fullwidth-code-point": "^3.0.0",
"strip-ansi": "^6.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/yargs/node_modules/strip-ansi": {
"version": "6.0.1",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
"integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
"dev": true,
"dependencies": {
"ansi-regex": "^5.0.1"
},
"engines": {
"node": ">=8"
}
},
"node_modules/yauzl": {
"version": "2.10.0",
"resolved": "https://registry.npmjs.org/yauzl/-/yauzl-2.10.0.tgz",
Update npm packages
2022-10-16 09:09:38 +02:00
"integrity": "sha512-p4a9I6X6nu6IhoGmBqAcbJy1mlC4j27vEPZX9F4L4/vZT3Lyq1VkFHw/V/PUcB9Buo+DG3iHkT0x3Qya58zc3g==",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
"dependencies": {
"buffer-crc32": "~0.2.3",
"fd-slicer": "~1.1.0"
}
},
"node_modules/yazl": {
"version": "2.5.1",
"resolved": "https://registry.npmjs.org/yazl/-/yazl-2.5.1.tgz",
"integrity": "sha512-phENi2PLiHnHb6QBVot+dJnaAZ0xosj7p3fWl+znIjBDlnMI2PsZCJZ306BPTFOaHf5qdDEI8x5qFrSOBN5vrw==",
"dev": true,
"dependencies": {
"buffer-crc32": "~0.2.3"
}
Update npm packages
2022-08-07 10:20:21 +02:00
},
"node_modules/yocto-queue": {
"version": "0.1.0",
"resolved": "https://registry.npmjs.org/yocto-queue/-/yocto-queue-0.1.0.tgz",
"integrity": "sha512-rVksvsnNCdJ/ohGc6xgPwyN8eheCxsiLM8mxuE/t/mOVqJewPuO1miLpTHQiRgTKCLexL4MeAFVagts7HmNZ2Q==",
"dev": true,
"engines": {
"node": ">=10"
},
"funding": {
"url": "https://github.com/sponsors/sindresorhus"
}
Update npm packages
2024-03-17 13:50:21 +01:00
},
"node_modules/zod": {
Update dependencies to the most recent versions
2024-06-11 15:08:55 +02:00
"version": "3.23.8",
"resolved": "https://registry.npmjs.org/zod/-/zod-3.23.8.tgz",
"integrity": "sha512-XBx9AXhXktjUqnepgTiE5flcKIYWi/rme0Eaj+5Y0lftuGBq+jyRu/md4WnuxqgP1ubdpNCsYEYPxrzVHD8d6g==",
Update npm packages
2024-03-17 13:50:21 +01:00
"dev": true,
Update dependencies to the most recent versions
2024-05-28 19:24:24 +02:00
"license": "MIT",
Update npm packages
2024-03-17 13:50:21 +01:00
"funding": {
"url": "https://github.com/sponsors/colinhacks"
}
Convert `package-lock.json` to lock file version 2 Since NPM 7, which is over a year old now since it released in October 2020, NPM automatically transforms lock files from version 1 to version 2. In the NPM 7 release notes they reported: "One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree." Not only is this change backwards compatible (so older versions of NPM will still be able to install everything as expected), reproducability is also a nice property to have and modern NPM versions will otherwise constantly do the conversion anyway, causing contributors to explicitly have to revert the change. Therefore, I believe we should do this now since it doesn't break backwards compatibility for consumers of this file. It only means that producers of this file (i.e., us contributors) need to use at least NPM 7 or higher (as of writing NPM 8 is even available). According to https://nodejs.org/en/download/releases/ this means contributors should at least run Node.js 15.0.0, while 17.1.0 is the most recent as of writing, so to me that sounds reasonable to ask.
2021-11-28 19:11:09 +01:00
}
Include `package-lock.json` for reproducible builds
2018-05-20 15:19:49 +02:00
}
}
Copy permalink