-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds yarn support with npm fallback #270
Conversation
just why? have one or the other, won't this cause more possible dependency issues that its solves? |
@elisechant this shouldn't cause any issues I'm aware of, do you have a specific case in mind? |
@tizmagik yarn's dependency tree is more strict than npm's without a shrink-wrap. Potentially you could have developers with environments that have dependency discrepancies. I think the solution here should look like either using npm (perhaps with shrink-wrap) or yarn. |
Thanks for the clarification @elisechant The main benefit of this PR is to speed up CI, especially the e2e tests. Users are free to continue using npm, even if yarn is installed globally on their machine. The only impact on users is for the With all that being said, the reason why yarn is so compelling is not only because it's faster, but also because it's precisely more strict than npm+shrinkwrap. Shrinkwrap is unfortunately notoriously inconsistent and difficult to work with, so having the option of using yarn (iff it's installed globally) I see as a real benefit. I'm sure we'd also be happy to accept a PR that adds an option to force using npm on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been thinking a bit about this and I'm wondering if just yarn being installed is enough reason to use yarn? I'm thinking particularly about projects that will want to use private dependencies. Devs may have yarn installed but not be able to use it for a particular project. Do you think it's worth investigating a way to allow users to force npm? I'm not sure how exactly it would work since kytConfig doesnt exist during setup etc. Maybe a flag? Not sure where else you would need to specify
cc @jaredmcdonald @delambo
@@ -19,6 +20,7 @@ const { | |||
const kytPkg = require(path.join(__dirname, '../../package.json')); | |||
|
|||
module.exports = (config, flags, args) => { | |||
logger.info('kyt version: ', kytPkg.version); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's this for?
@@ -7,7 +7,7 @@ | |||
"kyt": "cli/index.js" | |||
}, | |||
"engines": { | |||
"node": ">=6.1.0" | |||
"node": ">=6.0.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whats the reasoning for this?
* master: (35 commits) creates local copies of packages so e2e tests use latest code (#345) adds style and script linter packages (#344) now using npm version to check for kyt-cli updates (#337) Adds kyt version option to setup command (#343) make lint-script command; lint now runs scripts and style (#339) Adds bootstrap scripts (#341) fixes test coverage command (#342) Run test from root directory (#336) Monorepo (#330) [ci skip] document Jest/Watchman issue and common workaround (#334) Catch SIGINT (#332) Fixes e2e tests (#326) Removes deprecated reflect eslint rule (#325) Upgrade Linter dependencies (#289) [doc]fix path of eslintrc and stylelintrc (#321) Update unit tests for changes made to resolve #303 (#318) adds ISSUE_TEMPLATE (#317) Adds rfc template (#316) document possible kyt setup repository url formats (#314) Overwrites default npm init test script on setup (#293) ... # Conflicts: # .travis.yml # e2e_tests/tests/cli.test.js # package.json # packages/kyt-cli/cli/actions/setup.js
This is technically blocked by The issue is yarn resolves relative paths incorrectly. Fixed in yarnpkg/yarn#1498 Possible Workarounds:
|
* master: not sure why but this rule is choking on travis but not locally reinstating update and hardcoding bash shebang er I have no idea why that last thing didn't work; re-expand but format script commands fixes travis build better fixes travis build fixes top level lint command # Conflicts: # e2e_tests/utils/psKill.js
v0.18.0 has been released (v0.18.1 is the latest as of this comment): |
* master: Fixes typos in static-starter-kyt
… e2e tests had wrong code
…all doesnt hoist the symlink
@@ -0,0 +1,15 @@ | |||
#!/bin/sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of creating an optional yarn-install-modules file, do you all think it would be better to add a conditional to the install-modules file that will use yarn if it exists. Something like:
if ! type "yarn" > /dev/null; then
yarn 2>&1
else
npm i 2>&1
fi
I use bootstrap.sh a lot to update, so it would be helpful if the install-modules script used yarn.
* master: Fix typo (#379) kyt-cli version bump (#376) updates the kyt-cli version (#370) fixes cli starter kyt path bug (#369) Adds prep for 0.4.0 release candidate (#368) Adding identity object property; fixing preprocessor bug (#367) Adds yarn support with npm fallback (#270) Fix typo (#366) Match imports by file ext in Jest test config (#363)
Closes #254