Some repositories seem to have a mismatch between the package manager used in TravisCI configuration (.travis-ci.yml) and the lock file committed to the repository.
@simonihmig reported this issue when migrating ember-responsive-image. The .travis-ci.yml was using npm but a yarn.lock was committed to the repository.
I faced the same issue when migrating ember-leaflet. But in this case the .travis-ci.yml was using yarn but a package-lock.json was committed to the repository.
It seems like common that TravisCI configuration does not use the package manager expected by the project. I guess the project changed the package manager at some point of time but missed to update .travis-ci.yml and Ember CLI Update configuration.
In most cases a mismatch between package manager used in TravisCI configuration and expected by the project is not an issue. TravisCI picks correct package manager automatically unless install step is provided explicitly. TravisCI configuration created by Ember CLI blueprints only overwrites the install step for the Floating Dependencies scenario. As lock file should be ignored for that scenario using the wrong package manager does not cause any harm.
I think package manager should be detected based on existing yarn.lock or package-lock.json. Even if migrating an existing TravisCI configuration. Existing yarn.lock or package-lock.json seems to be the source of truth. I don't see a use case for using another package manager in CI. Relying on TravisCI configuration and not existing lock file does not seem to provide any value. But it has the risk to migrate bugs...
Some repositories seem to have a mismatch between the package manager used in TravisCI configuration (
.travis-ci.yml) and the lock file committed to the repository.@simonihmig reported this issue when migrating ember-responsive-image. The
.travis-ci.ymlwas using npm but ayarn.lockwas committed to the repository.I faced the same issue when migrating ember-leaflet. But in this case the
.travis-ci.ymlwas using yarn but apackage-lock.jsonwas committed to the repository.It seems like common that TravisCI configuration does not use the package manager expected by the project. I guess the project changed the package manager at some point of time but missed to update
.travis-ci.ymland Ember CLI Update configuration.In most cases a mismatch between package manager used in TravisCI configuration and expected by the project is not an issue. TravisCI picks correct package manager automatically unless
installstep is provided explicitly. TravisCI configuration created by Ember CLI blueprints only overwrites theinstallstep for the Floating Dependencies scenario. As lock file should be ignored for that scenario using the wrong package manager does not cause any harm.I think package manager should be detected based on existing
yarn.lockorpackage-lock.json. Even if migrating an existing TravisCI configuration. Existingyarn.lockorpackage-lock.jsonseems to be the source of truth. I don't see a use case for using another package manager in CI. Relying on TravisCI configuration and not existing lock file does not seem to provide any value. But it has the risk to migrate bugs...