New Case Study:See how Anthropic automated 95% of dependency reviews with Socket.Learn More →
package-json-type
Advanced tools
package-json-type - npm Package Compare versions
Comparing version 1.0.1 to 1.0.2
| { | ||
| "name": "package-json-type", | ||
| "version": "1.0.1", | ||
| "version": "1.0.2", | ||
| "author": { | ||
@@ -12,3 +12,3 @@ "email": "ajaxlab7@gmail.com", | ||
| }, | ||
| "description": "A TypeScript definition for the package descriptor file.", | ||
| "description": "A TypeScript definition for the package.json", | ||
| "devDependencies": { | ||
@@ -31,4 +31,6 @@ "rimraf": "^2.6.2", | ||
| "package.json", | ||
| "package.d.ts", | ||
| "typescript", | ||
| "definition" | ||
| "definition", | ||
| "d.ts" | ||
| ], | ||
@@ -35,0 +37,0 @@ "license": "MIT", |
@@ -0,0 +0,0 @@ # package-json-type |
@@ -14,4 +14,4 @@ /** | ||
| * An executable file which will be installed into the PATH | ||
| * with a package install. npm will symlink that file into | ||
| * prefix/bin for global installs, or ./node_modules/.bin/ | ||
| * with a package install. `npm` will symlink that file into | ||
| * `prefix/bin` for global installs, or `./node_modules/.bin/` | ||
| * for local installs. | ||
@@ -27,5 +27,5 @@ * | ||
| * | ||
| * For example, with linux if you install myapp, | ||
| * it'll create a symlink from the cli.js script | ||
| * to /usr/local/bin/myapp. | ||
| * For example, with linux if you install `myapp`, | ||
| * it'll create a symlink from the `cli.js` script | ||
| * to `/usr/local/bin/myapp`. | ||
| * @see https://docs.npmjs.com/files/package.json#bin | ||
@@ -50,3 +50,3 @@ */ | ||
| /** | ||
| * A "config" object can be used to set configuration parameters | ||
| * A `config` object can be used to set configuration parameters | ||
| * used in package scripts that persist across upgrades. | ||
@@ -61,5 +61,5 @@ * For instance, if a package had the following: | ||
| * ``` | ||
| * and then had a “start” command that then referenced the | ||
| * npm_package_config_port environment variable, | ||
| * then the user could override that by doing npm config set foo:port 8001. | ||
| * and then had a `start` command that then referenced the | ||
| * `npm_package_config_port` environment variable, | ||
| * then the user could override that by doing npm config set `foo:port 8001`. | ||
| * @see https://docs.npmjs.com/files/package.json#config | ||
@@ -131,3 +131,3 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-config | ||
| * Tell people where the bulk of your library is. | ||
| * Nothing special is done with the lib folder | ||
| * Nothing special is done with the `lib` folder | ||
| * in any way, but it's useful meta info. | ||
@@ -139,3 +139,3 @@ */ | ||
| * A folder that is full of man pages. Sugar to generate | ||
| * a "man" array by walking the folder. | ||
| * a `man` array by walking the folder. | ||
| */ | ||
@@ -187,4 +187,4 @@ man?: string; | ||
| * An executable file which will be installed into the PATH | ||
| * with a package install. npm will symlink that file into | ||
| * prefix/bin for global installs, or ./node_modules/.bin/ | ||
| * with a package install. `npm` will symlink that file into | ||
| * `prefix/bin` for global installs, or `./node_modules/.bin/` | ||
| * for local installs. | ||
@@ -200,5 +200,5 @@ * | ||
| * | ||
| * For example, with linux if you install myapp, | ||
| * it'll create a symlink from the cli.js script | ||
| * to /usr/local/bin/myapp. | ||
| * For example, with linux if you install `myapp`, | ||
| * it'll create a symlink from the `cli.js` script | ||
| * to `/usr/local/bin/myapp`. | ||
| * @see https://docs.npmjs.com/files/package.json#bin | ||
@@ -210,3 +210,3 @@ */ | ||
| * This is a hint to the module which is meant to be | ||
| * used client-side instead of nodejs. | ||
| * used "client-side" instead of "nodejs". | ||
| * @see https://github.com/defunctzombie/package-browser-field-spec | ||
@@ -235,3 +235,3 @@ * @see http://2ality.com/2017/04/setting-up-multi-platform-packages.html#browser-browser-specific-code | ||
| /** | ||
| * A "config" object can be used to set configuration parameters | ||
| * A "`config`" object can be used to set configuration parameters | ||
| * used in package scripts that persist across upgrades. | ||
@@ -246,3 +246,3 @@ * For instance, if a package had the following: | ||
| * ``` | ||
| * and then had a “start” command that then referenced the | ||
| * and then had a "`start`" command that then referenced the | ||
| * npm_package_config_port environment variable, | ||
@@ -256,3 +256,3 @@ * then the user could override that by doing npm config set foo:port 8001. | ||
| /** | ||
| * If there is an AUTHORS file in the root of your package, | ||
| * If there is an `AUTHORS` file in the root of your package, | ||
| * npm will treat each line as a Name <email> (url) format, | ||
@@ -268,3 +268,3 @@ * where email and url are optional. Lines which start with a # or are blank, | ||
| * If your code only runs on certain cpu architectures, you can specify which ones. | ||
| * This checks against process.arch. | ||
| * This checks against `process.arch`. | ||
| * @see https://docs.npmjs.com/files/package.json#cpu | ||
@@ -331,3 +331,3 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-cpu | ||
| * You can specify the version of node that your stuff works on. | ||
| * You can also specify which versions of npm are capable | ||
| * You can also specify which versions of `npm` are capable | ||
| * of properly installing your program. | ||
@@ -342,3 +342,3 @@ * @see https://docs.npmjs.com/files/package.json#engines | ||
| * as a glob pattern. Omitting the field will make it default | ||
| * to ["*"], as it will include all files. | ||
| * to `["*"]`, as it will include all files. | ||
| * @see https://docs.npmjs.com/files/package.json#files | ||
@@ -351,3 +351,3 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-files | ||
| * If your package only allows one version of a given dependency, | ||
| * and you'd like to enforce the same behavior as yarn install --flat | ||
| * and you'd like to enforce the same behavior as `yarn install --flat` | ||
| * on the command line, set this to true. | ||
@@ -375,3 +375,3 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-flat | ||
| * to use it, and any restrictions you're placing on it. | ||
| * If you're using a common license such as BSD-2-Clause or MIT, | ||
| * If you're using a common license such as `BSD-2-Clause` or `MIT`, | ||
| * add a current {@link https://spdx.org/licenses/ | SPDX license identifier}. | ||
@@ -387,4 +387,4 @@ * @see https://docs.npmjs.com/files/package.json#license | ||
| * The main field is a module ID that is the primary entry point to your package. | ||
| * That is, if your package is named foo, and a user installs it, and then | ||
| * does require("foo"), then your main module's exports object will be returned. | ||
| * That is, if your package is named `foo`, and a user installs it, and then | ||
| * does `require("foo")`, then your main module's exports object will be returned. | ||
| * This should be a module ID relative to the root of your package folder. | ||
@@ -407,3 +407,3 @@ * For most modules, it makes the most sense to have a main script and often not much else. | ||
| * The name and version fields are optional if you don't want to publish your package. | ||
| * A name can be optionally prefixed by a scope, e.g. @types/lodash. | ||
| * A name can be optionally prefixed by a scope, e.g. `@types/lodash`. | ||
| * @see https://docs.npmjs.com/files/package.json#name | ||
@@ -417,4 +417,4 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-name | ||
| * if it cannot be found or fails to install, then you may put it | ||
| * in the optionalDependencies object. This is a map of package name | ||
| * to version or url, just like the dependencies object. | ||
| * in the `optionalDependencies` object. This is a map of package name | ||
| * to version or url, just like the `dependencies` object. | ||
| * The difference is that build failures do not cause installation to fail. | ||
@@ -449,3 +449,3 @@ * It is still your program's responsibility to handle the lack of the dependency. | ||
| * It is purely there for informational purposes. It is now recommended | ||
| * that you install any binaries as local devDependencies wherever possible. | ||
| * that you install any binaries as local `devDependencies` wherever possible. | ||
| * @deprecated | ||
@@ -456,3 +456,3 @@ */ | ||
| /** | ||
| * If you set "private": true in your package.json, then npm will refuse to publish it. | ||
| * If you set "`private`": true in your `package.json`, then `npm` will refuse to publish it. | ||
| * This is a way to prevent accidental publication of private repositories. | ||
@@ -470,7 +470,7 @@ * If you would like to ensure that a given package is only ever published to | ||
| * This is a set of config values that will be used at publish-time. | ||
| * It's especially handy if you want to set the tag, registry or access, | ||
| * so that you can ensure that a given package is not tagged with “latest”, | ||
| * It's especially handy if you want to set the `tag`, `registry` or `access`, | ||
| * so that you can ensure that a given package is not tagged with `“latest”`, | ||
| * published to the global public registry or that a scoped module is private by default. | ||
| * Any config values can be overridden, but only "tag", "registry" and | ||
| * "access" probably matter for the purposes of publishing. | ||
| * Any config values can be overridden, but only "`tag`", "`registry`" and | ||
| * "`access`" probably matter for the purposes of publishing. | ||
| * See npm-config to see the list of config options that can be overridden. | ||
@@ -556,3 +556,3 @@ * * Public Registry | ||
| /** | ||
| * The "scripts" property is a dictionary containing script commands | ||
| * The "`scripts`" property is a dictionary containing script commands | ||
| * that are run at various times in the lifecycle of your package. | ||
@@ -578,3 +578,3 @@ * The key is the lifecycle event, and the value is the command to run at that point. | ||
| * Indicate the main declaration file in your package.json. | ||
| * Set the types property to point to your bundled declaration file. | ||
| * Set the `types` property to point to your bundled declaration file. | ||
| * ```json | ||
@@ -602,7 +602,7 @@ * { | ||
| * This is a set of config values that will be used at publish-time. | ||
| * It's especially handy if you want to set the tag, registry or access, | ||
| * so that you can ensure that a given package is not tagged with “latest”, | ||
| * It's especially handy if you want to set the `tag`, `registry` or `access`, | ||
| * so that you can ensure that a given package is not tagged with `“latest”`, | ||
| * published to the global public registry or that a scoped module is private by default. | ||
| * Any config values can be overridden, but only "tag", "registry" and | ||
| * "access" probably matter for the purposes of publishing. | ||
| * Any config values can be overridden, but only "`tag`", "`registry`" and | ||
| * "`access`" probably matter for the purposes of publishing. | ||
| * See npm-config to see the list of config options that can be overridden. | ||
@@ -685,3 +685,3 @@ * * Public Registry | ||
| /** | ||
| * The "scripts" property is a dictionary containing script commands | ||
| * The "`scripts`" property is a dictionary containing script commands | ||
| * that are run at various times in the lifecycle of your package. | ||
@@ -737,3 +737,3 @@ * The key is the lifecycle event, and the value is the command to run at that point. | ||
| /** | ||
| * It checks against process.arc. | ||
| * It checks against `process.arc`. | ||
| * @see https://docs.npmjs.com/files/package.json#cpu | ||
@@ -740,0 +740,0 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-cpu |
@@ -13,4 +13,4 @@ /** | ||
| * An executable file which will be installed into the PATH | ||
| * with a package install. npm will symlink that file into | ||
| * prefix/bin for global installs, or ./node_modules/.bin/ | ||
| * with a package install. `npm` will symlink that file into | ||
| * `prefix/bin` for global installs, or `./node_modules/.bin/` | ||
| * for local installs. | ||
@@ -26,5 +26,5 @@ * | ||
| * | ||
| * For example, with linux if you install myapp, | ||
| * it'll create a symlink from the cli.js script | ||
| * to /usr/local/bin/myapp. | ||
| * For example, with linux if you install `myapp`, | ||
| * it'll create a symlink from the `cli.js` script | ||
| * to `/usr/local/bin/myapp`. | ||
| * @see https://docs.npmjs.com/files/package.json#bin | ||
@@ -47,3 +47,3 @@ */ | ||
| /** | ||
| * A "config" object can be used to set configuration parameters | ||
| * A `config` object can be used to set configuration parameters | ||
| * used in package scripts that persist across upgrades. | ||
@@ -58,5 +58,5 @@ * For instance, if a package had the following: | ||
| * ``` | ||
| * and then had a “start” command that then referenced the | ||
| * npm_package_config_port environment variable, | ||
| * then the user could override that by doing npm config set foo:port 8001. | ||
| * and then had a `start` command that then referenced the | ||
| * `npm_package_config_port` environment variable, | ||
| * then the user could override that by doing npm config set `foo:port 8001`. | ||
| * @see https://docs.npmjs.com/files/package.json#config | ||
@@ -122,3 +122,3 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-config | ||
| * Tell people where the bulk of your library is. | ||
| * Nothing special is done with the lib folder | ||
| * Nothing special is done with the `lib` folder | ||
| * in any way, but it's useful meta info. | ||
@@ -129,3 +129,3 @@ */ | ||
| * A folder that is full of man pages. Sugar to generate | ||
| * a "man" array by walking the folder. | ||
| * a `man` array by walking the folder. | ||
| */ | ||
@@ -171,4 +171,4 @@ man?: string; | ||
| * An executable file which will be installed into the PATH | ||
| * with a package install. npm will symlink that file into | ||
| * prefix/bin for global installs, or ./node_modules/.bin/ | ||
| * with a package install. `npm` will symlink that file into | ||
| * `prefix/bin` for global installs, or `./node_modules/.bin/` | ||
| * for local installs. | ||
@@ -184,5 +184,5 @@ * | ||
| * | ||
| * For example, with linux if you install myapp, | ||
| * it'll create a symlink from the cli.js script | ||
| * to /usr/local/bin/myapp. | ||
| * For example, with linux if you install `myapp`, | ||
| * it'll create a symlink from the `cli.js` script | ||
| * to `/usr/local/bin/myapp`. | ||
| * @see https://docs.npmjs.com/files/package.json#bin | ||
@@ -193,3 +193,3 @@ */ | ||
| * This is a hint to the module which is meant to be | ||
| * used client-side instead of nodejs. | ||
| * used "client-side" instead of "nodejs". | ||
| * @see https://github.com/defunctzombie/package-browser-field-spec | ||
@@ -215,3 +215,3 @@ * @see http://2ality.com/2017/04/setting-up-multi-platform-packages.html#browser-browser-specific-code | ||
| /** | ||
| * A "config" object can be used to set configuration parameters | ||
| * A "`config`" object can be used to set configuration parameters | ||
| * used in package scripts that persist across upgrades. | ||
@@ -226,3 +226,3 @@ * For instance, if a package had the following: | ||
| * ``` | ||
| * and then had a “start” command that then referenced the | ||
| * and then had a "`start`" command that then referenced the | ||
| * npm_package_config_port environment variable, | ||
@@ -235,3 +235,3 @@ * then the user could override that by doing npm config set foo:port 8001. | ||
| /** | ||
| * If there is an AUTHORS file in the root of your package, | ||
| * If there is an `AUTHORS` file in the root of your package, | ||
| * npm will treat each line as a Name <email> (url) format, | ||
@@ -246,3 +246,3 @@ * where email and url are optional. Lines which start with a # or are blank, | ||
| * If your code only runs on certain cpu architectures, you can specify which ones. | ||
| * This checks against process.arch. | ||
| * This checks against `process.arch`. | ||
| * @see https://docs.npmjs.com/files/package.json#cpu | ||
@@ -304,3 +304,3 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-cpu | ||
| * You can specify the version of node that your stuff works on. | ||
| * You can also specify which versions of npm are capable | ||
| * You can also specify which versions of `npm` are capable | ||
| * of properly installing your program. | ||
@@ -314,3 +314,3 @@ * @see https://docs.npmjs.com/files/package.json#engines | ||
| * as a glob pattern. Omitting the field will make it default | ||
| * to ["*"], as it will include all files. | ||
| * to `["*"]`, as it will include all files. | ||
| * @see https://docs.npmjs.com/files/package.json#files | ||
@@ -322,3 +322,3 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-files | ||
| * If your package only allows one version of a given dependency, | ||
| * and you'd like to enforce the same behavior as yarn install --flat | ||
| * and you'd like to enforce the same behavior as `yarn install --flat` | ||
| * on the command line, set this to true. | ||
@@ -343,3 +343,3 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-flat | ||
| * to use it, and any restrictions you're placing on it. | ||
| * If you're using a common license such as BSD-2-Clause or MIT, | ||
| * If you're using a common license such as `BSD-2-Clause` or `MIT`, | ||
| * add a current {@link https://spdx.org/licenses/ | SPDX license identifier}. | ||
@@ -354,4 +354,4 @@ * @see https://docs.npmjs.com/files/package.json#license | ||
| * The main field is a module ID that is the primary entry point to your package. | ||
| * That is, if your package is named foo, and a user installs it, and then | ||
| * does require("foo"), then your main module's exports object will be returned. | ||
| * That is, if your package is named `foo`, and a user installs it, and then | ||
| * does `require("foo")`, then your main module's exports object will be returned. | ||
| * This should be a module ID relative to the root of your package folder. | ||
@@ -372,3 +372,3 @@ * For most modules, it makes the most sense to have a main script and often not much else. | ||
| * The name and version fields are optional if you don't want to publish your package. | ||
| * A name can be optionally prefixed by a scope, e.g. @types/lodash. | ||
| * A name can be optionally prefixed by a scope, e.g. `@types/lodash`. | ||
| * @see https://docs.npmjs.com/files/package.json#name | ||
@@ -381,4 +381,4 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-name | ||
| * if it cannot be found or fails to install, then you may put it | ||
| * in the optionalDependencies object. This is a map of package name | ||
| * to version or url, just like the dependencies object. | ||
| * in the `optionalDependencies` object. This is a map of package name | ||
| * to version or url, just like the `dependencies` object. | ||
| * The difference is that build failures do not cause installation to fail. | ||
@@ -410,3 +410,3 @@ * It is still your program's responsibility to handle the lack of the dependency. | ||
| * It is purely there for informational purposes. It is now recommended | ||
| * that you install any binaries as local devDependencies wherever possible. | ||
| * that you install any binaries as local `devDependencies` wherever possible. | ||
| * @deprecated | ||
@@ -416,3 +416,3 @@ */ | ||
| /** | ||
| * If you set "private": true in your package.json, then npm will refuse to publish it. | ||
| * If you set "`private`": true in your `package.json`, then `npm` will refuse to publish it. | ||
| * This is a way to prevent accidental publication of private repositories. | ||
@@ -429,7 +429,7 @@ * If you would like to ensure that a given package is only ever published to | ||
| * This is a set of config values that will be used at publish-time. | ||
| * It's especially handy if you want to set the tag, registry or access, | ||
| * so that you can ensure that a given package is not tagged with “latest”, | ||
| * It's especially handy if you want to set the `tag`, `registry` or `access`, | ||
| * so that you can ensure that a given package is not tagged with `“latest”`, | ||
| * published to the global public registry or that a scoped module is private by default. | ||
| * Any config values can be overridden, but only "tag", "registry" and | ||
| * "access" probably matter for the purposes of publishing. | ||
| * Any config values can be overridden, but only "`tag`", "`registry`" and | ||
| * "`access`" probably matter for the purposes of publishing. | ||
| * See npm-config to see the list of config options that can be overridden. | ||
@@ -512,3 +512,3 @@ * * Public Registry | ||
| /** | ||
| * The "scripts" property is a dictionary containing script commands | ||
| * The "`scripts`" property is a dictionary containing script commands | ||
| * that are run at various times in the lifecycle of your package. | ||
@@ -533,3 +533,3 @@ * The key is the lifecycle event, and the value is the command to run at that point. | ||
| * Indicate the main declaration file in your package.json. | ||
| * Set the types property to point to your bundled declaration file. | ||
| * Set the `types` property to point to your bundled declaration file. | ||
| * ```json | ||
@@ -555,7 +555,7 @@ * { | ||
| * This is a set of config values that will be used at publish-time. | ||
| * It's especially handy if you want to set the tag, registry or access, | ||
| * so that you can ensure that a given package is not tagged with “latest”, | ||
| * It's especially handy if you want to set the `tag`, `registry` or `access`, | ||
| * so that you can ensure that a given package is not tagged with `“latest”`, | ||
| * published to the global public registry or that a scoped module is private by default. | ||
| * Any config values can be overridden, but only "tag", "registry" and | ||
| * "access" probably matter for the purposes of publishing. | ||
| * Any config values can be overridden, but only "`tag`", "`registry`" and | ||
| * "`access`" probably matter for the purposes of publishing. | ||
| * See npm-config to see the list of config options that can be overridden. | ||
@@ -636,3 +636,3 @@ * * Public Registry | ||
| /** | ||
| * The "scripts" property is a dictionary containing script commands | ||
| * The "`scripts`" property is a dictionary containing script commands | ||
| * that are run at various times in the lifecycle of your package. | ||
@@ -687,3 +687,3 @@ * The key is the lifecycle event, and the value is the command to run at that point. | ||
| /** | ||
| * It checks against process.arc. | ||
| * It checks against `process.arc`. | ||
| * @see https://docs.npmjs.com/files/package.json#cpu | ||
@@ -690,0 +690,0 @@ * @see https://yarnpkg.com/en/docs/package-json#toc-cpu |
| "use strict"; | ||
| Object.defineProperty(exports, "__esModule", { value: true }); | ||
| //# sourceMappingURL=index.js.map |
Sorry, the diff of this file is not supported yet
No alert changes
Worsened metrics
- Total package byte prevSize
- decreased by-1.99%
71875
No dependency changes