ljharb / ls-engines

Determine if your dependency graph's stated "engines" criteria is met.

ls-engines

Determine if your dependency graph's stated "engines" criteria is met.

Example

> ls-engines
`package.json` found; building ideal tree from package.json...

Valid node version range: ^14 || ^13 || ^12 || ^11 || ^10 || ^9 || ^8 || ^7 || ^6 || ^5 || ^4 || ^0.12 || ^0.11 || ^0.10 || ^0.9 || ^0.8

Currently available, most recent, valid node major versions: v14.2, v13.14, v12.16.3, v11.15, v10.20.1, v9.11.2, v8.17, v7.10.1, v6.17.1, v5.12, v4.9.1, v0.12.18, v0.11.16, v0.10.48, v0.9.12, v0.8.28

Current node version, v13.7.0, is valid!

ls-engines takes a --mode option, which defaults to "auto", but can also be "actual", "virtual", or "ideal". ”actual“ reads from node_modules; ”virtual“ reads from a lockfile; “ideal” reads from package.json.

ls-engines's Issues

Silence output on success

This is a nice little tool you have here, but having this added to prepare script in many of our projects it would be nice to silence the output when the check is successful.

A good rule for CLI tools is to follow the UNIX philosophy regarding output.

I would prefer a breaking change and silence by default (as per the link above) and add a --verbose or --level flag. As an alternative solution a --silent flag could work, but then the question arises – what to silence. Only success output? All tips? Not errors should be silenced though.

Thoughts?

SyntaxError: Unexpected end of JSON input

Node 13.14.0, npx ls-engines

Doesn't validate the current package's stated engines criteria is met by it's dependencies.

It was a little bit unexpected what the result would be at first. I see it validates the current node version against all the dependencies of the module.

It would be nice to see that the current module "engines" is compatible with its dependencies' engines range. That way it can be a valuable addition to a CI build for libraries since we don't always have the opportunity to test on every node version before releasing. It would also catch any version changes from downstream modules which didn't come with a major version.

wrong message about engines field

C:\Users\xmr\Desktop\hugo-bin>ls-engines
`node_modules` found; loading tree from disk...

Valid node version range: ^13 || ^12 || ^11 || ^10 || ^9 || ^8 || ^7 || ^6

Currently available latest releases of each valid node major version: v13.7.0, v12.14.1, v11.15.0, v10.18.1, v9.11.2, v8.17.0, v7.10.1, v6.17.1

Current node version, v12.14.1, is valid!

Your “engines” field is either missing, or set to ”*”! Prefer explicitly setting a supported engine range.

You can fix this by running `ls-engines --save`, or by manually adding the following to your `package.json`:
"engines": {
  "node": "^13 || ^12 || ^11 || ^10 || ^9 || ^8 || ^7 || ^6"
}

The package.json file does have an engines property though:

https://github.com/fenneclab/hugo-bin/blob/a8c6fb39bdb2bcb559367c9f7e71cac60404f7f9/package.json#L36

Did I miss something?

List dependencies which violate local engines.node support

This is a nice tool, one feature that would be really nice is a way to have it assume that the local package.json#engines.node is correct. If my package.json supports {"node": ">=8"} and [email protected] is installed, instead of being told to bump my local version requirement I want to know that semver 7.1.0 is an inappropriate dependency.

when `engines.node` is explicitly set to `*`, still errors

I can't recall atm if this was intentional or not, but i have a package that actually does work on literally everything, and it forced me to use an actual range.

An in-range update of tape is breaking the build 🚨

---

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

---

The devDependency tape was updated from 5.0.0-next.5 to 5.0.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

tape is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ Travis CI - Branch: The build failed.

---

Commits

The new version differs by 8 commits.

• cd81a40 v5.0.0
• 3bb97f1 [Breaking] remove full "lib" export; replace with explicit exports
• d021e9d [examples] add ecstatic
• 5b9c442 [readme] Add link to tape-player (in-process reporter)
• f24491d [Dev Deps] update falafel
• 6fd0691 [Deps] update deep-equal, minimist, object-is, resolve
• f5d0899 [Docs] add an optional emoji version for tap-spec consumer
• 8ba3668 [Tests] Fix simple typo, placehodler -> placeholder

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

An in-range update of auto-changelog is breaking the build 🚨

---

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

---

The devDependency auto-changelog was updated from 1.16.2 to 1.16.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

auto-changelog is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ Travis CI - Branch: The build failed.

---

Commits

The new version differs by 4 commits.

• b2f3c98 1.16.3
• 1ced7a8 Bump packages
• 107445f Add FUNDING.yml
• a8da4cd Bump handlebars from 4.1.2 to 4.3.0 (#147)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

How can I use this after npm i

How can I use this after installing, is there are specific command or script?

An in-range update of pacote is breaking the build 🚨

The dependency pacote was updated from 11.0.0 to 11.0.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

pacote is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ Travis CI - Branch: The build errored.

---

Commits

The new version differs by 3 commits.

• 4545243 11.0.1
• 8c7fbb3 [email protected]
• a55359e update deps

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

An in-range update of semver is breaking the build 🚨

The dependency semver was updated from 7.1.2 to 7.1.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

semver is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ Travis CI - Branch: The build failed.

---

Commits

The new version differs by 3 commits.

• 6e7982f 7.1.3
• ebcf4df prefer const over let
• 7c2ec1c refactor: replace var with let

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Add option to scan sub-directories and combine results

Some of my projects have sub projects, for example my express project will have a react sub project for the frontend. It would be nice if there were an option, if true it will check sub folders as well for node_modules or a .lock file.

.
├── node_modules
├── frontend
│   ├── admin
|   |   ├── node_modules
|   |   ├── package.json
|   |   └── yarn.lock
│   └── home
|   |   ├── node_modules
|   |   ├── package.json
|   |   └── yarn.lock
├── package.json
└── yarn.lock

Currently I run them individually for all three projects and get three different results. So maybe something like a --recursive option to do this?

yarn ls-engines --recursive=true

Add ability to only apply to production deps

This is the primary use case imo.

Supprt pnpm-lock.yaml in virtual mode

ls-engines doesn't support pnpm-lock.yaml in --mode=virtual

An in-range update of pacote is breaking the build 🚨

---

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

---

The dependency pacote was updated from 11.1.4 to 11.1.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

pacote is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ Travis CI - Branch: The build failed.

---

Commits

The new version differs by 3 commits.

• 095dd3d 11.1.5
• fc2a84d update cacache to latest
• afbed4d Use @npmcli/run-script instead of spawning 'npm run'

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Security Advisory: Vulnerability in `phin` Dependency

I received a security advisory indicating that there is a moderate severity vulnerability in the phin dependency used by the get-json dependency in the ls-engines package. The phin package may include sensitive headers in subsequent requests after a redirect. There is currently no fix available for this vulnerability.

Audit Report:

# npm audit report

phin  <3.7.1
Severity: moderate
phin may include sensitive headers in subsequent requests after redirect - https://github.com/advisories/GHSA-x565-32qp-m3vf
No fix available
node_modules/phin
  get-json  1.0.0 - 1.0.1
  Depends on vulnerable versions of phin
  node_modules/get-json
    ls-engines  *
    Depends on vulnerable versions of get-json
    node_modules/ls-engines

3 moderate severity vulnerabilities

Some issues need review, and may require choosing
a different dependency.

Dependency Tree:

[email protected]
└─┬ [email protected]
  └─┬ [email protected]
    └── [email protected]

Steps to Reproduce:

1. Run npm audit to see the vulnerability report.
2. Run npm ls phin to view the dependency tree involving the phin package.

Context:
We are using ls-engines as a development dependency in our semantic-release project. While this does not directly affect our users, it is important to address the vulnerability for the security and integrity of our development environment.

References:

• https://github.com/semantic-release/semantic-release/security/dependabot/33