pkg-types - npm Package Compare versions

Comparing version 1.1.3 to 1.2.0

dist/index.d.ts

@@ -82,11 +82,9 @@ import { ResolveOptions as ResolveOptions$1 } from 'mlly';
     /**
-       * The name is what your thing is called.
-       * Some rules:
-  
-           - The name must be less than or equal to 214 characters. This includes the scope for scoped packages.
-           - The name can’t start with a dot or an underscore.
-           - New packages must not have uppercase letters in the name.
-           - The name ends up being part of a URL, an argument on the command line, and a folder name. Therefore, the name can’t contain any non-URL-safe characters.
-  
-       */
+     * The name is what your thing is called.
+     * Some rules:
+     * - The name must be less than or equal to 214 characters. This includes the scope for scoped packages.
+     * - The name can’t start with a dot or an underscore.
+     * - New packages must not have uppercase letters in the name.
+     * - The name ends up being part of a URL, an argument on the command line, and a folder name. Therefore, the name can’t contain any non-URL-safe characters.
+     */
     name?: string;
@@ -160,2 +158,6 @@ /**
     /**
+     * The `unpkg` field is used to specify the URL to a UMD module for your package. This is used by default in the unpkg.com CDN service.
+     */
+    unpkg?: string;
+    /**
      * A map of command name to local file name. On install, npm will symlink that file into `prefix/bin` for global installs, or `./node_modules/.bin/` for local installs.
@@ -225,5 +227,91 @@ */
     /**
-     * The optional engines field is used to specify the versions of npm and node that your stuff works on.
+     * The field is used to define a set of sub-packages (or workspaces) within a monorepo.
+     *
+     * This field is an array of glob patterns or an object with specific configurations for managing
+     * multiple packages in a single repository.
      */
     workspaces?: string[];
+    /**
+     * The field is is used to specify different TypeScript declaration files for
+     * different versions of TypeScript, allowing for version-specific type definitions.
+     */
+    typesVersions?: Record<string, Record<string, string[]>>;
+    /**
+     * You can specify which operating systems your module will run on:
+     * ```json
+     * {
+     *   "os": ["darwin", "linux"]
+     * }
+     * ```
+     * You can also block instead of allowing operating systems, just prepend the blocked os with a '!':
+     * ```json
+     * {
+     *   "os": ["!win32"]
+     * }
+     * ```
+     * The host operating system is determined by `process.platform`
+     * It is allowed to both block and allow an item, although there isn't any good reason to do this.
+     */
+    os?: string[];
+    /**
+     * If your code only runs on certain cpu architectures, you can specify which ones.
+     * ```json
+     * {
+     *   "cpu": ["x64", "ia32"]
+     * }
+     * ```
+     * Like the `os` option, you can also block architectures:
+     * ```json
+     * {
+     *   "cpu": ["!arm", "!mips"]
+     * }
+     * ```
+     * The host architecture is determined by `process.arch`
+     */
+    cpu?: string[];
+    /**
+     * This is a set of config values that will be used at publish-time.
+     */
+    publishConfig?: {
+        /**
+         * The registry that will be used if the package is published.
+         */
+        registry: string;
+        /**
+         * The tag that will be used if the package is published.
+         */
+        tag: string;
+        /**
+         * The access level that will be used if the package is published.
+         */
+        access: "public" | "restricted";
+        /**
+         * **pnpm-only**
+         *
+         * By default, for portability reasons, no files except those listed in
+         * the bin field will be marked as executable in the resulting package
+         * archive. The executableFiles field lets you declare additional fields
+         * that must have the executable flag (+x) set even if
+         * they aren't directly accessible through the bin field.
+         */
+        executableFiles?: string[];
+        /**
+         * **pnpm-only**
+         *
+         * You also can use the field `publishConfig.directory` to customize
+         * the published subdirectory relative to the current `package.json`.
+         *
+         * It is expected to have a modified version of the current package in
+         * the specified directory (usually using third party build tools).
+         */
+        directory?: string;
+        /**
+         * **pnpm-only**
+         *
+         * When set to `true`, the project will be symlinked from the
+         * `publishConfig.directory` location during local development.
+         * @default true
+         */
+        linkDirectory?: boolean;
+    } & Pick<PackageJson, "bin" | "main" | "exports" | "types" | "typings" | "module" | "browser" | "unpkg" | "typesVersions" | "os" | "cpu">;
     [key: string]: any;
@@ -230,0 +318,0 @@ }

package.json

 {
   "name": "pkg-types",
-  "version": "1.1.3",
+  "version": "1.2.0",
   "description": "Node.js utilities and TypeScript definitions for `package.json` and `tsconfig.json`",
@@ -33,16 +33,16 @@ "license": "MIT",
   "devDependencies": {
-    "@types/node": "^20.14.9",
-    "@vitest/coverage-v8": "^1.6.0",
-    "automd": "^0.3.7",
+    "@types/node": "^22.5.0",
+    "@vitest/coverage-v8": "^2.0.5",
+    "automd": "^0.3.8",
     "changelogen": "^0.5.5",
-    "eslint": "^9.6.0",
+    "eslint": "^9.9.0",
     "eslint-config-unjs": "^0.3.2",
-    "expect-type": "^0.19.0",
+    "expect-type": "^0.20.0",
     "jiti": "^1.21.6",
-    "prettier": "^3.3.2",
-    "typescript": "^5.5.2",
+    "prettier": "^3.3.3",
+    "typescript": "^5.5.4",
     "unbuild": "^2.0.0",
-    "vitest": "^1.6.0"
+    "vitest": "^2.0.5"
   },
   "packageManager": "pnpm@9.1.0"
 }

No alert changes

Improved metrics

Total package byte prevSize

72646

15.41%

Lines of code

716

14.38%

No dependency changes