package-locks-checks
v0.0.8
Published
Validate packages inconsistencies to protect your production environments from unexpected dependencies versions
Downloads
189
Maintainers
Readme
package-locks-checks
Validate packages inconsistenciesinconsistencies to protect your production environments from unexpected dependencies versions.
Prevent common situations (mainly when working on a dev team):
- Dev sometimes includes open wide version ranges on package.json, that later will be installed a most recent on your build/production environment and break your project
- Some devs on team uses npm to install packages while others uses yarn, causing a lock file inconsistency, probably breaking your build/production environment with messages like "Your project contains lock files generated by tools other than Yarn"
- Versions being updated on package.json file, without calling a
yarn
ornpm install
after that, to replicate that version to lock file
Default rules:
- Disallow to have a versions range (ex: ^1.0.4 or 1.0.x) other than specific version (ex: 1.0.4) on package dependencies
- Disallow to have package-lock.json and yarn.lock at same time
- Disallow to have different hashed versions on package.json and yarn.lock file
Other rules could be added, suggest it on the issues.
Installation
Install globally:
yarn global add package-locks-checks
or
npm install -g package-locks-checks
Or run with npx:
npx package-locks-checks
Usage
To force check with all default validator just run
package-locks-checks
This will validate all rules and return success if everything is ok.
. . .
To check on a different folder you can run
package-locks-checks --basePath './api'
Options:
Param Default Description
-pm, --packageManager <npm,yarn,pnpm> yarn Select packageManager
-p, --basePath <path> ./ Base path to load package files
-f, --packageFile <filename> ./package.json Full path to package.json file
-r, --allowRange <boolean> false Allow to have a range (ex: 1 or 1.x or ^1.0.4) other than specific version (ex: 1.0 or 1.0.4) on package dependencies
-mlf, --allowMultipleLockFiles <boolean> false Allow to have package-lock.json and yarn.lock at same time', false)
-uyl, --allowUnmatchedYarnLock <boolean> false Allow to have different hashed versions on package.json and yarn.lock file', false)
Exit codes
0 = No errors
1 = Errors were founds in the package-lock.json files
2 = Folder or package.json was not found
To be implemented
- Detect "preferred" package manager, to validate npm issues as well
- Validate package-lock.json with package.lock versions
- Use hasLockfile to validate multiple lock files
- Auto publish package on npm when merging do main
- Update exit codes with 2 other than 1 when folder missing
- Check for yarn.lock before integrity yarn check, pnpm-lock.yaml with pnpm, and so
Related links
- Lockfiles should be committed on all projects
- About semantic versioning
- Semantic Versioning 2.0.0
- yarn install --frozen-lockfile should be the default behavior
Problems? Ideas?
License
MIT © Tiago Gouvêa