yarnpkg/yarn

Engines check broken for nightly builds

Open

#2,172 opened on Dec 7, 2016

View on GitHub
 (12 comments) (0 reactions) (0 assignees)JavaScript (41,514 stars) (2,731 forks)batch import
cat-bughelp wanted

Description

We have a package which has the following engines field:

"engines": {
  "node": ">=6.0.0",
  "yarn": ">=0.18.0",
  "npm": ">=4.0.0"
}

in package.json. As there is not yet a stable "msi" package for Windows users for installation we thought of installing the latest nightly. Unfortunately yarn does not seem to be happy with the installed version. Possibly this is because the version check is somehow flawed.

Output from installing:

yarn install v0.18.0-20161123.1451
[1/4] Resolving packages...
[2/4] Fetching packages...
error advanced-boilerplate@0.14.7: The engine "yarn" is incompatible with this module. Expected version ">=0.18.0".
error Found incompatible module
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

This seems to be a bug as v0.18.0-20161123.1451 should be successfully matched by >=0.18.0.

Contributor guide

Tech stack
javascriptnodejs
Domain
cli
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
basic Node.js knowledgeunderstanding of semantic versioning
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
60
Research direction
Investigate the semver comparison logic in yarn's engine validation. Look at how the engine requirement string is parsed and compared to the installed yarn version. The issue is likely in the version comparison function where pre release tags (like ' 20161123.1451') are not handled correctly for the '>=' operator. Check the `semver` npm package usage in the codebase, particularly in files like `src/package.js` or `src/install.js`. Consider if the solution is to properly compare pre release versions by stripping the pre release suffix or using a semver library that supports pre release comparison.