npm/yarn detection not working?
simonihmig opened this issue · 4 comments
I ran this tool on https://github.com/kaliber5/ember-responsive-image, and it created the npm-based workflow, although there is a yarn.lock! 🤔
Haven't looked further into it yet...
I guess you run the script on the state before this merge request: simonihmig/responsive-image#77
As the repository had a .travis.yml at that time the script migrates that one. It does not calculate defaults in that case.
The TravisCI configuration of the repository was using npm: https://github.com/kaliber5/ember-responsive-image/blob/4db6f8d0c8a3aa2435e193e187aa45f75fa14056/.travis.yml#L38-L39 So this was as expected.
Wondering if using NPM in TravisCI even though the repository uses yarn is a common mistake. In that case we might want to warn the user about it.
I guess you run the script on the state before this merge request: simonihmig/responsive-image#77
Yes, the PR was the result of running the script + some manual tweaks.
The TravisCI configuration of the repository was using npm... So this was as expected.
Hm, ok. I was looking at this line, so thought the "switch" for yarn vs npm was made based on the existance of yarn.lock in the repo, not what's inside .travis.yml:
What am I missing? 🤔
The TravisCI configuration of the repository was using npm... So this was as expected.
Hm, ok. I was looking at this line, so thought the "switch" for yarn vs npm was made based on the existance of
yarn.lockin the repo, not what's inside.travis.yml:What am I missing? thinking
The script supports different parser. Which ever is able to return meaningful configuration is used. It first looks for configuration stored by a previous run. Afterwards it looks for a .travis.yml. Only if both is not available it takes the defaults.
I plan to support an interactive mode, which allows the user to pick the parser and makes this less magical. See #35 for details.
Ok, got it. Thanks!