Struct PackageJson

pub struct PackageJson {

    pub name: String,
    pub version: String,
    pub description: Option<String>,
    pub keywords: Option<Vec<String>>,
    pub homepage: Option<String>,
    pub bugs: Option<PackageBugs>,
    pub license: Option<String>,
    pub author: Option<PackagePeople>,
    pub contributors: Option<Vec<PackagePeople>>,
    pub maintainers: Option<Vec<PackagePeople>>,
    pub funding: Option<Vec<PackageFunding>>,
    pub files: Option<Vec<String>>,
    pub main: String,
    pub browser: Option<String>,
    pub bin: Option<PackageBin>,
    pub man: Option<PackageMan>,
    pub directories: Option<PackageDirectories>,
    pub repository: Option<PackageRepository>,
    pub scripts: HashMap<String, String>,
    pub config: Option<HashMap<String, Value>>,
    pub dependencies: Option<PackageDependencies>,
    pub dev_dependencies: Option<PackageDependencies>,
    pub peer_dependencies: Option<PackageDependencies>,
    pub peer_dependencies_meta: Option<HashMap<String, HashMap<String, bool>>>,
    pub bundled_dependencies: Option<Vec<String>>,
    pub optional_dependencies: Option<PackageDependencies>,
    pub overrides: Option<HashMap<String, String>>,
    pub engines: Option<HashMap<String, String>>,
    pub os: Option<Vec<String>>,
    pub cpu: Option<Vec<String>>,
    pub private: bool,
    pub publish_config: Option<HashMap<String, String>>,
    pub workspaces: Option<Vec<String>>,
    pub type: String,
    pub types: Option<String>,
    pub typings: Option<String>,
    pub unknowns: HashMap<String, Value>,
}

A package.json is a JSON file that exists in the root of a JavaScript/Node.js project. It holds metadata relevant to the project and it’s used for managing the project’s dependencies, scripts, version and a whole lot more.

package.json schema from official npm documentation, see also json-schemas repo and json-schemas online

Fields

name: String

The name for the npm package

version: String

The version for the npm package

description: Option<String>

The description helps people discover your package, as it’s listed in npm search.

keywords: Option<Vec<String>>

The keywords helps people discover your package as it’s listed in npm search.

homepage: Option<String>

The url to the project homepage.

bugs: Option<PackageBugs>

The url to your project’s issue tracker and / or the email address to which issues should be reported. These are helpful for people who encounter issues with your package.

license: Option<String>

The license of the package.

author: Option<PackagePeople>

The author of the package.

contributors: Option<Vec<PackagePeople>>

A list of people who contributed to this package.

maintainers: Option<Vec<PackagePeople>>

A list of people who maintains this package.

funding: Option<Vec<PackageFunding>>

Used to inform about ways to help fund development of the package.

files: Option<Vec<String>>

The files field is an array of files to include in your project. If you name a folder in the array, then it will also include the files inside that folder.

main: String

The main field is a module ID that is the primary entry point to your program. 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 relative to the root of your package folder.

For most modules, it makes the most sense to have a main script and often not much else.

If main is not set it defaults to index.js in the package’s root folder.

browser: Option<String>

If your module is meant to be used client-side the browser field should be used instead of the main field. This is helpful to hint users that it might rely on primitives that aren’t available in Node.js modules. (e.g. window)

bin: Option<PackageBin>

A lot of packages have one or more executable files that they’d like to install into the PATH. npm makes this pretty easy (in fact, it uses this feature to install the “npm” executable.)

To use this, supply a bin field in your package.json which is a map of command name to local file name. When this package is installed globally, that file will be linked where global bins go so it is available to run by name. When this package is installed as a dependency in another package, the file will be linked where it will be available to that package either directly by npm exec or by name in other scripts when invoking them via npm run-script.

man: Option<PackageMan>

Specify either a single file or an array of filenames to put in place for the man program to find.

If only a single file is provided, then it’s installed such that it is the result from man <pkgname>, regardless of its actual filename.

directories: Option<PackageDirectories>

The CommonJS Packages spec details a few ways that you can indicate the structure of your package using a directories object. If you look at npm’s package.json, you’ll see that it has directories for doc, lib, and man.

repository: Option<PackageRepository>

Specify the place where your code lives. This is helpful for people who want to contribute. If the git repo is on GitHub, then the npm docs command will be able to find you.

scripts: HashMap<String, String>

A dictionary containing script commands that are run at various times in the lifecycle of your package. The key is the lifecycle event, and the value is the command to run at that point.

config: Option<HashMap<String, Value>>

A config object can be used to set configuration parameters used in package scripts that persist across upgrades.

dependencies: Option<PackageDependencies>

Dependencies are specified in a simple object that maps a package name to a version range. The version range is a string which has one or more space-separated descriptors. Dependencies can also be identified with a tarball or git URL.

Please do not put test harnesses or transpilers or other “development” time tools in your dependencies object. See devDependencies.

dev_dependencies: Option<PackageDependencies>

If someone is planning on downloading and using your module in their program, then they probably don’t want or need to download and build the external test or documentation framework that you use.

In this case, it’s best to map these additional items in a devDependencies object.

peer_dependencies: Option<PackageDependencies>

In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a require of this host. This is usually referred to as a plugin. Notably, your module may be exposing a specific interface, expected and specified by the host documentation.

peer_dependencies_meta: Option<HashMap<String, HashMap<String, bool>>>

When a user installs your package, npm will emit warnings if packages specified in peerDependencies are not already installed. The peerDependenciesMeta field serves to provide npm more information on how your peer dependencies are to be used. Specifically, it allows peer dependencies to be marked as optional.

bundled_dependencies: Option<Vec<String>>

An array of package names that will be bundled when publishing the package.

optional_dependencies: Option<PackageDependencies>

If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the optionalDependencies object.

overrides: Option<HashMap<String, String>>

If you need to make specific changes to dependencies of your dependencies, for example replacing the version of a dependency with a known security issue, replacing an existing dependency with a fork, or making sure that the same version of a package is used everywhere, then you may add an override.

Overrides provide a way to replace a package in your dependency tree with another version, or another package entirely. These changes can be scoped as specific or as vague as desired.

engines: Option<HashMap<String, String>>

Specify which engines your module will run on.

os: Option<Vec<String>>

Specify which operating systems your module will run on.

cpu: Option<Vec<String>>

Specify which cpu your module will run on.

private: bool

If set to true, then npm will refuse to publish it.

publish_config: Option<HashMap<String, String>>

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”, published to the global public registry or that a scoped module is private by default.

workspaces: Option<Vec<String>>

The optional workspaces field is an array of file patterns that describes locations within the local file system that the install client should look up to find each workspace that needs to be symlinked to the top level node_modules folder.

type: String

When set to “module”, the type field allows a package to specify all .js files within are ES modules. If the “type” field is omitted or set to “commonjs”, all .js files are treated as CommonJS.

types: Option<String>

Set the types property to point to your bundled declaration file. This is useful for packages that have a large number of types, but only a few of which are used.

typings: Option<String>

Note that the typings field is synonymous with “types”, and could be used as well.

unknowns: HashMap<String, Value>

Any unknown fields should be placed in unknown field.

Trait Implementations

impl AsMut<PackageJson> for PackageJsonManager

fn as_mut(&mut self) -> &mut PackageJson

Return a mutable reference to the current PackageJson struct.

impl AsRef<PackageJson> for PackageJsonManager

fn as_ref(&self) -> &PackageJson

Return a immutable reference to the current PackageJson struct.

impl Debug for PackageJson

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for PackageJson

fn default() -> PackageJson

Returns the “default value” for a type.

impl<'de> Deserialize<'de> for PackageJson

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Serialize for PackageJson

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.