lockfile-lint vs lockfile vs proper-lockfile
Lockfile Management
lockfile-lintlockfileproper-lockfileSimilar Packages:

Lockfile Management

Lockfile management libraries in Node.js help developers handle package-lock.json or yarn.lock files, which are automatically generated by package managers to ensure consistent installations across environments. These libraries provide tools for reading, writing, validating, and modifying lockfiles, making it easier to manage dependencies, detect issues, and maintain reproducible builds. They are particularly useful in CI/CD pipelines, automated scripts, and projects with strict dependency management requirements. lockfile is a simple utility for reading and writing lockfiles, lockfile-lint focuses on validating and linting lockfiles to ensure their integrity, while proper-lockfile provides a more comprehensive solution for managing lockfiles with features like adding, removing, and updating dependencies while preserving the file's structure and integrity.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
lockfile-lint218,41885239.1 kB33 months agoApache-2.0
lockfile0259-128 years agoISC
proper-lockfile0276-215 years agoMIT

Feature Comparison: lockfile-lint vs lockfile vs proper-lockfile

Lockfile Reading and Writing

  • lockfile-lint:

    lockfile-lint focuses on validating lockfiles rather than reading or writing them. It checks the lockfile for common issues, such as duplicate entries, missing fields, and incorrect formatting, ensuring that the lockfile is consistent and reliable.

  • lockfile:

    lockfile provides basic functionality for reading and writing lockfiles. It allows you to parse existing lockfiles and generate new ones, but it does not offer advanced features like modifying or validating the lockfile structure.

  • proper-lockfile:

    proper-lockfile offers comprehensive reading and writing capabilities, including the ability to modify existing lockfiles. It supports adding, removing, and updating dependencies while preserving the lockfile's integrity, making it a more versatile choice for complex projects.

Lockfile Validation

  • lockfile-lint:

    lockfile-lint provides robust validation of lockfiles. It checks for various issues that could affect dependency resolution, such as duplicate package entries, missing version ranges, and incorrect formatting. This makes it a valuable tool for maintaining high-quality lockfiles.

  • lockfile:

    lockfile does not include any validation features. It simply reads and writes lockfiles without checking their integrity or structure, which means it relies on the developer to ensure the lockfile is correct.

  • proper-lockfile:

    proper-lockfile does not focus on validation but ensures that the lockfile is written correctly when making modifications. It maintains the lockfile's structure and integrity during read and write operations, reducing the risk of introducing errors.

Dependency Modification

  • lockfile-lint:

    lockfile-lint does not modify dependencies; it only validates the lockfile. It can help identify issues that need to be fixed, but it does not make any changes to the lockfile or the dependencies themselves.

  • lockfile:

    lockfile does not support modifying dependencies directly. It is primarily a read/write utility, so any changes to the lockfile must be done manually or with another tool.

  • proper-lockfile:

    proper-lockfile excels at modifying dependencies within the lockfile. It provides APIs for adding, removing, and updating packages, making it a powerful tool for managing dependencies programmatically while ensuring the lockfile remains accurate.

Integration with CI/CD

  • lockfile-lint:

    lockfile-lint is highly suitable for CI/CD integration, as it automatically validates lockfiles and reports any issues. This helps catch problems early in the development process and ensures that only clean, validated lockfiles are merged into the codebase.

  • lockfile:

    lockfile can be integrated into CI/CD pipelines for basic lockfile operations, such as reading and writing lockfiles during build processes. However, it does not provide any built-in validation or error handling, so additional scripts may be needed to ensure proper usage.

  • proper-lockfile:

    proper-lockfile can be used in CI/CD pipelines for managing lockfiles, especially when modifications are needed. Its ability to programmatically update the lockfile makes it useful for automated scripts that need to adjust dependencies as part of the build process.

Ease of Use: Code Examples

  • lockfile-lint:

    Validating Lockfiles with lockfile-lint

    const { lint } = require('lockfile-lint');
    
    // Lint a lockfile
    lint({ path: 'package-lock.json' }).then((result) => {
      console.log(result);
    });
    
  • lockfile:

    Reading and Writing Lockfiles with lockfile

    const lockfile = require('lockfile');
    
    // Read a lockfile
    const data = lockfile.readSync('package-lock.json');
    console.log(data);
    
    // Write a lockfile
    lockfile.writeSync('package-lock.json', data);
    
  • proper-lockfile:

    Modifying Lockfiles with proper-lockfile

    const properLockfile = require('proper-lockfile');
    
    // Add a dependency
    await properLockfile.add('package-lock.json', 'new-package', '1.0.0');
    
    // Remove a dependency
    await properLockfile.remove('package-lock.json', 'old-package');
    
    // Update a dependency
    await properLockfile.update('package-lock.json', 'existing-package', '2.0.0');
    

How to Choose: lockfile-lint vs lockfile vs proper-lockfile

  • lockfile-lint:

    Choose lockfile-lint if you want to ensure the integrity and consistency of your lockfiles. It is particularly useful for teams and CI/CD pipelines where validating lockfiles before merging changes is important to prevent issues with dependency resolution.

  • lockfile:

    Choose lockfile if you need a lightweight and straightforward tool for reading and writing lockfiles without any additional complexity. It is ideal for simple projects or scripts where you need basic lockfile manipulation.

  • proper-lockfile:

    Choose proper-lockfile if you need a robust solution for managing lockfiles with advanced features like adding, removing, and updating dependencies while maintaining the lockfile's structure. It is suitable for larger projects or monorepos where more control over lockfile management is required.

README for lockfile-lint

lockfile-lint

A CLI to lint a lockfile for security policies

npm version license downloads build codecov Known Vulnerabilities Security Responsible Disclosure

About

A CLI tool to lint a lockfile for security policies

Install

npm install --save lockfile-lint

Usage

lockfile-lint can be installed per a project scope, or globally and exposes a lockfile-lint executable that should be practiced during builds, CIs, and general static code analysis procedures to ensure that lockfiles are kept up to date with pre-defined security and usage policies.

lockfile-lint --type <yarn|npm> --path <path-to-lockfile> --validate-https --allowed-hosts <host-to-match> --allowed-urls <urls-to-match>

Supported lockfiles:

  • npm's package-lock.json and npm-shrinkwrap.json
  • yarn's yarn.lock

Example

An example of running the linter with debug output for a yarn lockfile and asserting that all resources are using the official npm registry as source for packages:

DEBUG=* lockfile-lint --path yarn.lock --type yarn --allowed-hosts npm

Example 2: specify hostnames and enforce the use of HTTPS as a protocol

lockfile-lint --path yarn.lock --allowed-hosts registry.yarnpkg.com --validate-https
  • --type yarn is ommitted since lockfile-lint can figure it out on it's own
  • --allowed-hosts explicitly set to match yarn's mirror host

Example 3: allow the lockfile to contain packages served over github and so need to specify github.com as a host as well as the git+https: as a valid URI scheme

lockfile-lint --path yarn.lock --allowed-hosts yarn github.com --allowed-schemes "https:" "git+https:"
  • --allowed-hosts explicitly set to match github.com as a host and specifies yarn as the alias for yarn's official mirror host
  • --allowed-schemes is used instead of validate-https and it explicitly allows both https: and git+https: as the HTTP Scheme for the github URL. Note that --allowed-schemes and --validate-https are mutually exclusive.

Example 4: allow the lockfile to contain a package which resolves to a specific URL specified by the --allowed-urls option while all other packages must resolve to yarn as specified by --allowed-hosts

lockfile-lint --path yarn.lock --allowed-hosts yarn --allowed-urls https://github.com/lirantal/lockfile-lint#d30ce73a3e5977dede29450df1c79b09f02779b2
  • --allowed-hosts allows packages from yarn only
  • --allowed-urls overrides allowed-hosts and allows a specific Github URL to pass validation

CLI command options

command line argumentdescriptionimplemented
--path, -ppath to the lockfile but you can also provide a glob matching pattern as long as it isn't expanded by a shell like bash or zsh. If that's the case, you can provide it as a string, for example: -p '/Users/lirantal/repos/**/package-lock.json' to match multiple lockfiles
--type, -tlockfile type, options are npm or yarn
--format, -fsets what type of report output is desired, one of [ pretty, plain ] with plain removing colors & status symbols from output
--validate-https, -svalidates the use of HTTPS as protocol schema for all resources in the lockfile
--allowed-hosts, -avalidates a list of allowed hosts to be used for all resources in the lockfile. Supported short-hands aliases are npm, yarn, and verdaccio which will match URLs https://registry.npmjs.org, https://registry.yarnpkg.com and https://registry.verdaccio.org respectively
--allowed-schemes, -oallowed URI schemes such as "https:", "http", "git+ssh:", or "git+https:"
--allowed-urls, -uallowed URLs (e.g. https://github.com/some-org/some-repo#some-hash)
--empty-hostname, -eallow empty hostnames, or set to false if you wish for a stricter policy
--validate-package-names, -nvalidates that the resolved URL matches the package name
--validate-integrity, -ivalidates the integrity field is a sha512 hash
--allowed-package-name-aliases, -lallow package name aliases to be used by specifying package name and their alias as pairs (e.g: string-width-cjs:string-width)
--integrity-excludeexclude packages from the --validate-integrity check

File-Based Configuration

Lockfile-lint uses cosmiconfig for configuration file support. This means you can configure the above options via (in order of precedence):

  • A "lockfile-lint" key in your package.json file.
  • A .lockfile-lintrc file, written in JSON or YAML, with optional extensions: .json/.yaml/.yml (without extension takes precedence).
  • A .lockfile-lintrc.js, .lockfile-lintrc.cjs, or .lockfile-lintrc.mjs file that exports an object.
  • A lockfile-lint.config.js, lockfile-lint.config.cjs, or lockfile-lint.config.mjs file that exports an object.

ESM syntax is supported in .mjs files. For example:

export default {
  path: 'yarn.lock',
  type: 'yarn',
  allowedHosts: ['npm', 'yarn'],
  validateHttps: true
}

The configuration file will be resolved starting from the current working directory, and searching up the file tree until a config file is (or isn't) found. Command-line options take precedence over any file-based configuration.

The options accepted in the configuration file are the same as the options above in camelcase (e.g. "path", "allowedHosts").

References

Contributing

Please consult CONTRIBUTING for guidelines on contributing to this project.

Author

lockfile-lint © Liran Tal, Released under the Apache-2.0 License.