Last 12 weeks · 30 commits
4 of 6 standards met
Upgrade and to newer versions in order to resolve 13 deprecation warnings. This comes at the cost of dropping support for Node.js and . These are the minimum (major version) upgrades necessary to achieve this goal. Note: some of the deprecation warnings are still present due to the dependency on , to resolve these too it would need to receive similar upgrades. Since you're maintaining both of these packages I figured I can start with one PR and see if you're open to upgrading :slightly_smiling_face:
Repository: ljharb/ls-engines. Description: Determine if your dependency graph's stated "engines" criteria is met. Stars: 56, Forks: 4. Primary language: JavaScript. Languages: JavaScript (100%). License: MIT. Topics: engines, ls-engines, node, npm, package, validate. Open PRs: 1, open issues: 3. Last activity: 2mo ago. Community health: 85%. Top contributors: ljharb, XhmikosR, travi.
Hello, I have a project for which I'm trying to use ls-engines to identify the minimum node version for and upon inspecting the requirements myself I ran into a notable edge case that I'm not sure about the choices for: Upon inspection, the package had the most recent engine requirement, stating . Notably, this explicitly excludes node version 21. However, the result of ls-engines produces as the result, which will erroneously accept version 21. I believe the desired behavior should be to either inherit the same requirement as in this case, or just default to the highest of the specified values (). Practically speaking wrt implementation, it may make sense to track which versions are excluded by dependencies to validate the output does not conflict.
I received a security advisory indicating that there is a moderate severity vulnerability in the dependency used by the dependency in the package. The package may include sensitive headers in subsequent requests after a redirect. There is currently no fix available for this vulnerability. Audit Report: Dependency Tree: Steps to Reproduce: 1. Run to see the vulnerability report. 2. Run to view the dependency tree involving the package. Context: We are using as a development dependency in our 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