Use Yarn when available #114

gillchristian · 2016-12-11T18:30:54Z

This PR adds yarn as the default installer, and will fallback to npm when yarn is not installed.

Also adds an opt-out flag (--no-yarn) to override the behavior.

Since yarn's preinstall and postinstall issues are solved I believe is safe to add this option.

Fixes #98

SamVerschueren · 2016-12-11T18:47:40Z

I think we should automatically use yarn if a yarn.lock file is present.

gillchristian · 2016-12-11T19:33:59Z

@SamVerschueren what do you think about having the flag and also checking for the presence of yarn.lock?

EDIT: I just realized that it would be better to just just use yarn when the lock file is present, and have an opt-out (say for CLIs that do not support it). Will update to it in a couple of hours.

sindresorhus · 2016-12-12T16:01:25Z

cli.js

@@ -48,6 +50,7 @@ Promise

 		return options;
 	})
+	.then(options => Object.assign({}, options, {noYarn: noYarn(options)}))


This check should be done in index.js, not here.

And use https://github.com/sindresorhus/has-yarn

sindresorhus · 2016-12-12T16:05:04Z

index.js

@@ -33,6 +33,7 @@ module.exports = (input, opts) => {
 		opts.cleanup = false;
 	}

+	const manager = opts.noYarn ? 'npm' : 'yarn';


const bin = opts.yarn ? 'yarn' : 'npm';

And add a default value to line 28, using the hasYarn check.

sindresorhus · 2016-12-12T16:06:14Z

cli.js

@@ -19,6 +20,7 @@ const cli = meow(`
 	  --no-cleanup  Skips cleanup of node_modules
 	  --yolo        Skips cleanup and testing
 	  --tag         Publish under a given dist-tag
+	  --no-yarn     Do not use yarn (even if yarn.lock is present)


--no-yarn Don't use Yarn when available

sindresorhus · 2016-12-12T17:24:04Z

index.js

@@ -25,14 +26,16 @@ module.exports = (input, opts) => {
 	input = input || 'patch';

 	opts = Object.assign({
-		cleanup: true
+		cleanup: true,
+		yarn: !opts.noYarn && hasYarn()


yarn: opts.yarn !== false && hasYarn()

I just realized that --no-yarn gets parsed as opts.yarn, was sure it was parsed as opts.noYarn.

CI will fail anyways because opts is undefined on the tests. Will check why that happens.

Yes, actually, should be: yarn: opts && opts.yarn !== false && hasYarn()

sindresorhus · 2016-12-12T17:35:42Z

index.js

@@ -57,8 +60,8 @@ module.exports = (input, opts) => {
 				task: () => del('node_modules')
 			},
 			{
-				title: 'Installing dependencies',
-				task: () => exec('npm', ['install'])
+				title: `Installing dependencies${opts.yarn ? ' (using yarn)' : ''}`,


(using yarn) => using Yarn

gillchristian · 2016-12-12T17:55:43Z

@sindresorhus since yarn: opts && opts.yarn !== false && hasYarn() already solves the problem with the undefined opts should I change back the tests?

sindresorhus · 2016-12-12T23:19:58Z

index.js

@@ -57,8 +60,8 @@ module.exports = (input, opts) => {
 				task: () => del('node_modules')
 			},
 			{
-				title: 'Installing dependencies',
-				task: () => exec('npm', ['install'])
+				title: `Installing dependencies${opts.yarn ? ' using yarn' : ''}`,


Notice the capitalization in my previous comment: yarn => Yarn

sindresorhus · 2016-12-12T23:20:13Z

since yarn: opts && opts.yarn !== false && hasYarn() already solves the problem with the undefined opts should I change back the tests?

Yes

SamVerschueren · 2016-12-13T07:29:55Z

Just wondering about the ability of running np with Yarn without having a yarn.lock file. Because if the lockfile does not exist, np patch --yarn will create one for you and you will end up with local changes that aren't comitted to GitHub. Should we prevent this or is that up to the user to decide?

gillchristian · 2016-12-13T11:30:51Z

@SamVerschueren I removed the --yarn flag. np will default to Yarn when yarn.lock is there unless the --no-yarn flag is used.

SamVerschueren · 2016-12-13T11:34:46Z

Oh sweet. Totally missed that!

Edit: Probably because of ⏬

SamVerschueren · 2016-12-13T11:37:33Z

index.js

@@ -25,14 +26,16 @@ module.exports = (input, opts) => {
 	input = input || 'patch';

 	opts = Object.assign({
-		cleanup: true
+		cleanup: true,
+		yarn: opts && opts.yarn !== false && hasYarn()


I think this is wrong. Because if I ran np --yarn, this statement will be overridden with true and hasYarn() has no effect.

It should be

opts = Object.assign({ cleanup: true }, opts, { yarn: opts && opts.yarn !== false && hasYarn() });

You are right, updated 🙃

SamVerschueren

I have one last concern regarding the check. Currently it doesn't check if the yarn command is even available. For instance, a project that I don't own might have a lockfile. If I'm able to publish to npm, it will try to do that with Yarn which I might have not installed. Could we check that?

gillchristian · 2016-12-15T20:00:16Z

Yes that makes sense!

I'm not quite sure how to do it though 🤔

SamVerschueren · 2016-12-16T07:47:29Z

Maybe with node-which? Although there might a possibility @sindresorhus has a package for that 😆 ...

sindresorhus · 2016-12-16T22:49:40Z

Would be better to just try Yarn and handle the error if it doesn't exist. When it doesn't exists, execa rejects with an error that has a .code === 'ENOENT' property.

gillchristian · 2016-12-17T03:35:51Z

That makes sense, will add it on Sunday.

sindresorhus · 2017-01-05T13:03:56Z

@gillchristian Happy xmas and new year :) Any chance you would be able to finish this up?

gillchristian · 2017-01-05T13:15:38Z

Thanks, happy holidays to you too!

Yes, I've been kind of busy, sorry for the delay! Will try to finish soon 😄

gillchristian · 2017-01-06T02:11:50Z

index.js

 module.exports = (input, opts) => {
 	input = input || 'patch';

 	opts = Object.assign({
 		cleanup: true,
 		publish: true
 	}, opts, {
-		yarn: opts && opts.yarn !== false && hasYarn()


I'm not checking for yarn anymore since we are defaulting to it, and falling back when is not found.

gillchristian · 2017-01-06T02:15:37Z

index.js

@@ -22,14 +21,22 @@ const exec = (cmd, args) => {
 	).filter(Boolean);
 };

+const install = (bin, useYarn) => () => execa(bin, ['install'])


Is the first time I use execa, so there might be a better way of doing this 🙃

Also I would like to display a message, when falling back to npm, any suggestions on how @sindresorhus @SamVerschueren ?

Something like:

✔ Prerequisite check ✔ Git ✔ Cleanup ⠦ Installing dependencies using Yarn Yarn not installed, falling back to npm ✔ Running tests ✔ Bumping version ✔ Publishing package ✔ Pushing tags

I think you meant to use exec() here and below.

Also I would like to display a message, when falling back to npm, any suggestions on how

@SamVerschueren Any suggestion how to achieve this?

Maybe instead, we would create a new dynamic task if the Yarn one fails.

Example:

✔ Prerequisite check ✔ Git ✔ Cleanup - Installing dependencies using Yarn Yarn not installed, falling back to npm ⠦ Installing dependencies ✔ Running tests ✔ Bumping version ✔ Publishing package ✔ Pushing tags

Not sure if that's possible at the moment. The only thing you could do is work with the skipped functionality. The downside of this is that it decides upfront if the task is skipped or not. So if you're in the task function, it's not possible to skip it afterwards because something failed.

What you could do however is running yarn --version in the skip function and detect if that works. If not, you can show a skipped message. So that can be solved this way, something like this.

{ title: 'Installing dependencies using Yarn', skip: () => execa('yarn', '--version') .then(() => false) .catch(() => 'Yarn not installed, falling back to npm') }, task: () => execa('yarn') }

About adding a new task dynamically, never tried it, I don't think it would work. What we can do for now is showing the same line but with npm and skip if the dependencies are already installed with Yarn.

Solution 1

{ title: 'Installing dependencies using Yarn', skip: () => execa('yarn', '--version') .then(() => false) .catch(() => 'Yarn not installed, falling back to npm') }, task: ctx => { ctx.yarn = true; return execa('yarn'); } }, { title: 'Installing dependencies using npm', skip: ctx => { if (ctx.yarn) { return 'Dependencies already installed with Yarn'; } }, task: () => execa('npm', ['install']) }

But to be honest, that would look like crap. People might think we're going to install dependencies twice.

Solution 2

Using observables to show a message

{ title: 'Installing dependencies', task: ctx => { return new Observable(observer => { execa('yarn') .then(() => observer.complete()) .catch(() => { observer.next('Yarn not installed, falling back to npm'); return execa('npm', ['install']) .then(() => observer.complete()) .catch(err => observer.error(err)); }); }); } }

Solution 3

Add something like a visible or disabled property to Listr to dynamically show and hide tasks. That way we could use the skip function to detect if yarn is installed. If not, dynamically show the next task being Installing dependencies via npm.

The best option for now would be 2 I guess. But we will loose the execa output that is now generated because of npm install. So if we want to fix this on the long run, I will have to add new functionality to Listr.

Please provide me with feedback. If you have other solutions or needs that you want in order to solve this in the most elegant way possible, don't hesitate to throw it out. These are just the first things that come in my mind.

Thanks for the comprehensive reply Sam. I too think 2 would be the best solution right now, but would like to see 3 be possible eventually.

Add something like a visible or disabled property to Listr to dynamically show and hide tasks. That way we could use the skip function to detect if yarn is installed.

Sounds useful, but why not also make skip dynamic? You're pretty much treating the terminal as a canvas anyways, so anything could potentially be dynamic.

@SamVerschueren Could you open an issue about this on Listr, so we could continue this discussion there?

why not also make skip dynamic?

Can you elaborate on what you mean with this? skip accepts a promise as well, so in that sense it is dynamic. But maybe you're hinting at something else :).

Could you open an issue about this on Listr, so we could continue this discussion there?

Jup, I will. Just want to clarify the skip part first :).

Can you elaborate on what you mean with this? skip accepts a promise as well, so in that sense it is dynamic. But maybe you're hinting at something else :).

You said:

So if you're in the task function, it's not possible to skip it afterwards because something failed.

I'd like that to be possible.

Aha. Makes sense. I'll create two issues for these features and we can continue the discussion. I can probably work on this tomorrow so it might be better to wait a little longer to finish this PR.

I finally got into implementing these features 🎉 (released in 0.10.0). I even used the yarn with npm fallback as example of the feature. https://github.com/SamVerschueren/listr#enabling-tasks

Awesome! I will look into it and add it here.

Sorry for the delays btw, been really busy 😬

sindresorhus · 2017-01-07T17:19:33Z

index.js

@@ -21,19 +21,30 @@ const exec = (cmd, args) => {
 	).filter(Boolean);
 };

+const install = (bin, useYarn) => () => execa(bin, ['install'])
+	.then(c => c, e => {


I think you meant .catch() here. And use err, not e.

sindresorhus · 2017-01-07T17:21:02Z

And don't include the yarn.lock file.

jonathanrdelgado · 2017-02-02T21:31:10Z

Really looking forward to this feature!

@gillchristian Let me know if you don't have enough time for the modifications, I'd be more than happy to help.

gillchristian · 2017-02-02T21:36:38Z

Yes @jonathandelgado, I'm glad if you can help 😄

I will be able to work on it next week, some stuff came up this week so my spare time wasn't there.

jonathanrdelgado · 2017-02-02T22:26:09Z

@gillchristian Sounds good, working on it right now.

Scanning the PR, it looks like there was a previous discussion on using yarn only if yarn.lock is present (npm otherwise), but that behavior seemed to be replaced with yarn being default unconditionally (falling back to npm on failure). Is this the desired behavior, @sindresorhus? A brief outline of the desired conditionals would be great!

I would assume keep the previous behavior in which the default is based on yarn.lock being present, as that is a great indicator of what package manager the individual/project uses (though this may be narrow minded if an individual is using npm to install in a yarn locked project?).

Once I hear back on that functionality, I'll push changes to https://github.com/jonathandelgado/np and we can go from there.

SamVerschueren · 2017-02-03T05:34:07Z

You're right, we used to have the hasYarn() check but it was removed for some reason.

gillchristian · 2017-02-03T11:00:29Z

@jonathandelgado Yes, we removed hasYarn check in favor of just using yarn by default, and falling back to npm if yarn is not installed.

And for those that do not want to use yarn, there is a --no-yarn flag.

SamVerschueren · 2017-02-03T11:46:55Z

@gillchristian I think something went wrong in the communication. We still need to check if a yarn.lock file is present with the hasYarn() method. We don't want np to create a yarn.lock file if the file is not present but Yarn is available on the system. I release all my modules (or almost all of them) without yarn.lock but I have Yarn installed. Currently this means that np will always create a yarn.lock file which I don't want.

jonathanrdelgado · 2017-02-03T17:14:10Z

I have to agree with @SamVerschueren, I think the best course of action is defaulting based on the existence of a Yarn lock. I pushed the following changes to jonathandelgado/np#add-yarn-option - We can either merge them here, or I can create a separate PR.

Updated listr to 0.10.0 to use the enabled feature
Added the has-yarn dependency to detect if a Yarn lock is present
Removed the previous install method and put the function inline instead
Cleaned up options, I made the default hasYarn(), and allowed the flags to override
Added a --yarn flag to force Yarn even without a lock file (Opposite of --no-yarn)
Added separate tasks for Yarn and npm, allowing errors to be caught and a fail-over to take place (as recommended by @SamVerschueren)

I tested the following conditions:

Install without a Yarn lock should default to npm
Install with a Yarn lock should default to Yarn
Install without a Yarn lock and --yarn should foce Yarn
Install with a Yarn lock and --no-yarn should force npm
An error with Yarn will fail-over with the message Yarn not available, falling back to npm

I have only one issue with the current implementation. If I have a dependency I cannot install, for instance a OSX only module on the Windows platform, it also triggers a fail-over. execa gives an ENOENT code whether the command could not be found or the installation failed (on Windows at least). It appears to me the only difference in output is the stderr. I could create a regex to differentiate the two, but that seems hacky. Any suggestions?

gillchristian · 2017-02-03T17:20:56Z

Yes, I like that approach too. I guess I just misunderstood the discussion.

@jonathandelgado regarding the PR, I'm ok with both options.

SamVerschueren · 2017-02-03T18:17:45Z

@jonathandelgado The PR looks good.

Added a --yarn flag to force Yarn even without a lock file

I'm not sure about this one to be honest. This will produce a yarn.lock file which results in an uncomitted change.

jonathanrdelgado · 2017-02-03T18:55:17Z

@gillchristian If you could merge the two and squash after I fix the last problem, that would be great. I would prefer to keep all the discussion in a single PR for clarity's sake 😄

@SamVerschueren Good call, I removed that flag. meow will allow for the --yarn flag to work anyway, so no harm done if anyone has that edge case.

I have only one issue with the current implementation. If I have a dependency I cannot install, for instance a OSX only module on the Windows platform, it also triggers a fail-over. execa gives an ENOENT code whether the command could not be found or the installation failed (on Windows at least). It appears to me the only difference in output is the stderr. I could create a regex to differentiate the two, but that seems hacky. Any suggestions?

I thought more about this issue, I'm becoming more convinced we should really just throw the error and let the user deal with it rather than attempting an npm fail-over. If there is a lock file and they don't have Yarn installed (causing a fail-over), this might silently break modules with non-pinned versions, leading to issues down the road. A user should explicitly state if they want to abandon the lock using the --no-yarn flag.

Let me know what you think and I will implement the change. Thank you all for the speedy feedback!

jonathanrdelgado · 2017-02-07T21:06:34Z

I thought more about this issue, I'm becoming more convinced we should really just throw the error and let the user deal with it rather than attempting an npm fail-over. If there is a lock file and they don't have Yarn installed (causing a fail-over), this might silently break modules with non-pinned versions, leading to issues down the road. A user should explicitly state if they want to abandon the lock using the --no-yarn flag.

I went ahead and applied this behavior to my branch. I think the user should explicitly state they want to abandon the lock using --no-yarn rather than silently failing to npm.

@gillchristian Feel free to merge from jonathandelgado/np#add-yarn-option, it is really for review. Thanks!

sindresorhus · 2017-02-18T18:40:11Z

ping @gillchristian :)

SamVerschueren

Some small remarks

SamVerschueren · 2017-02-19T07:11:12Z

index.js

-	});
+		publish: true,
+		yarn: hasYarn()
+	}, opts);


This is not entirely correct. If they force yarn by using np --yarn while there is no lockfile, it will create a lockfile and I think we should prevent that. Instead I would do something like

opts = Object.assign({ cleanup: true, publish: true }, opts, { yarn: opts && opts.yarn && hasYarn() });

I think this would lead to confusing behavior. If the user wants to switch to Yarn, but has yet to generate a lockfile, it would seem as if this library isn't working.

I think the current implementation is fine, yet if you really want to ensure a lockfile is present, we should throw an error and alert the user what the issue is.

If you would force a lockfile it would fail downstream because it tries to push the tags but not everything is committed yet... So I vote against the possibility of enforcing a lockfile because it would fail...

Oh ok, I see the problem you are describing, I thought it did it in a different order.

I would propose adding something like the following for greater transparency.

if (!hasYarn() && opts.yarn){ throw new Error('Tried to use Yarn without a yarn.lock file.'); }

Do you agree?

Yes that makes sense I guess. Maybe something like

Could not use Yarn without yarn.lock file

@sindresorhus

SamVerschueren · 2017-02-19T07:12:38Z

index.js

-				task: install(bin, opts.yarn)
+				title: 'Installing dependencies using Yarn',
+				enabled: () => opts.yarn === true,
+				task: () => exec('yarn', ['install'])


We should implement a fallback as shown in the example of listr. If yarn fails because the binary is not available, we should fall back to npm as well.

I mentioned this issue a few times in the PR, i'll quote some relevant sources for context:

If I have a dependency I cannot install, for instance a OSX only module on the Windows platform, it also triggers a fail-over. execa gives an ENOENT code whether the command could not be found or the installation failed (on Windows at least). It appears to me the only difference in output is the stderr. I could create a regex to differentiate the two, but that seems hacky.

I thought more about this issue, I'm becoming more convinced we should really just throw the error and let the user deal with it rather than attempting an npm fail-over. If there is a lock file and they don't have Yarn installed (causing a fail-over), this might silently break modules with non-pinned versions, leading to issues down the road. A user should explicitly state if they want to abandon the lock using the --no-yarn flag.

I went ahead and applied this behavior to my branch. I think the user should explicitly state they want to abandon the lock using --no-yarn rather than silently failing to npm.

Conclusion:

Difficult to detect the binary is missing versus a standard error with the current library

If the binary is missing in that scenario, we shouldn't fallback to npm because it could silently break the build due to using non-pinned versions

Users should explicitly state they want to abandon the lock using --no-yarn to avoid the aforementioned issues, this allows for the fail-over you described, but not automatically.

Also, to further remark, this was implemented in 17091a0 but removed because of these concerns.

Difficult to detect the binary is missing versus a standard error with the current library

You can easily check for ENOENT

If the binary is missing in that scenario, we shouldn't fallback to npm because it could silently break the build due to using non-pinned versions

Did you know that a lockfile does nothing in a dependency? What I mean is that if I install (nom or yarn) execa which has a yarn.lock file, the lockfile is not taken into account for the dependencies of execa. So actually the only thing a lock file does is ensuring the same dependencies between contributors, not between contributors and its users. So falling back to npm is not a bad thing at all because you would end up with the exact same dependencies as your users! This is an important thing to keep in mind.

So yes, I still think we should fall back to npm if yarn does not exist. You can easily set a custom message in Listr to notify the users that yarn is not installed and that it's falling back to nom because of that. We can even recommend the users that they should install yarn, but we should not be the one that should enforce yarn upon our users. If they don't want it they don't want it, their choice.

You can easily check for ENOENT

If I have a dependency I cannot install, for instance a OSX only module on the Windows platform, it also triggers a fail-over. execa gives an ENOENT code whether the command could not be found or the installation failed (on Windows at least).

To your second point, yes, I am well aware how a yarn file works. My main issue was it can affect the local directory (and even np tests themselves). A user could be unaware that it defaulted to npm or doesn't understand the consequences of such. I know this type of issue wouldn't pop up often, but it is still a very real issue that could lead to a hard to diagnose problem.

SamVerschueren · 2017-02-19T07:13:08Z

package.json

    "inquirer": "^1.2.1",
-    "listr": "^0.6.1",
+    "listr": "^0.10.0",


@sindresorhus Because we skip quite some versions here, we should test thoroughly first.

Master is currently on ^0.9.0 so this shouldn't be a problem, this PR just has an old base.

You can easily rebase with git rebase master. We cannot merge automatically now because of conflicts.

I agree, ping @gillchristian - or better yet, could you just give me write access to that repo?

@jonathandelgado sorry once again 😬
I just gave you push access to my fork

jonathanrdelgado · 2017-03-02T21:15:46Z

Alright, just squashed history and rebased, thanks for the write access @gillchristian!

Added Could not use Yarn without yarn.lock file warning
Fixed conflict with package.json via rebase

Going to stick with my previous comments on falling back to NPM. Hopefully this will be the final review.

SamVerschueren · 2017-03-02T21:48:14Z

index.js

-				title: 'Installing dependencies',
+				title: 'Installing dependencies using Yarn',
+				enabled: () => opts.yarn === true,
+				task: () => exec('yarn', ['install'])


It's just yarn

They both work, this way is more clear on the intent.

Oh okay, didn't event know it worked :p. I always type yarn because it's faster. So fine for me for using the more verbose one.

Late to the party, but I'm wondering if it makes sense to add the --pure-lockfile flag since rimraf'ing the node_modules folder and doing a yarn install can generate a different lockfile and will fail the "Bumping version" step because the Git working directory is not clean.

doing a yarn install can generate a different lockfile

I don't think it is, that's the whole idea of the lock file... Unless you run yarn upgrade. Or am I wrong? I never experienced a changed yarn.lock file after running yarn.

This can happen when a dependency gets upgraded (using NPM perhaps) but the lockfile wasn't regenerated.

I'm not quite sure what the best course of action would be, maybe failing isn't so bad in hindsight 🤔

sindresorhus · 2017-03-15T09:33:03Z

Great work @gillchristian and @jonathandelgado 🎉

Would either or both of you be interested in being a maintainer on this project? Sam and I could use some help triaging and fixing issues and other things. No worries if not though :)

SamVerschueren · 2017-03-15T10:03:40Z

Sam and I could use some help triaging and fixing issues and other things.

One sidenote, we don't accept every feature request as we don't want to bloat this module with too many features. It's already quite feature rich at the moment. But any help would be more then welcome :).

gillchristian · 2017-03-15T12:21:22Z

Yes I would like to help, I cannot promise to be available all the time but I'll do my best 😄

rarkins · 2017-03-16T15:53:21Z

Yarn will regenerate the Yarn lock file if the package.json has differences in dependencies since the lock file was last generated.

Ie

If package.json dependencies unchanged since last yarn.lock generation = use yarn lock exactly, do not change it

Else all bets are off: regenerate yarn lock file based on current contents of package.json

In my opinion np should "fail" if the else case happens (it is a mistake to have updated package json dependencies and not yarn.lock). The best way to trigger this failure is via yarn itself and not wait for the git check.

sindresorhus · 2017-03-29T07:03:48Z

@gillchristian Cool! I've invited you to the repo. If you're not sure what to do now, going through the open issues and commenting your thoughts would be a good start.

gillchristian changed the title ~~Add yarn flag to allow install dependencies with yarn.~~ Add flag to allow installing dependencies with yarn. Dec 11, 2016

gillchristian changed the title ~~Add flag to allow installing dependencies with yarn.~~ Use yarn when there is a yarn.lock Dec 12, 2016

sindresorhus changed the title ~~Use yarn when there is a yarn.lock~~ Use Yarn when available Dec 12, 2016

sindresorhus requested changes Dec 12, 2016

View reviewed changes

sindresorhus reviewed Dec 12, 2016

View reviewed changes

SamVerschueren requested changes Dec 13, 2016

View reviewed changes

SamVerschueren requested changes Dec 15, 2016

View reviewed changes

gillchristian commented Jan 6, 2017

View reviewed changes

sindresorhus requested changes Jan 7, 2017

View reviewed changes

This was referenced Jan 18, 2017

Add enabled property to a task SamVerschueren/listr#42

Closed

Support skipping a task while performing the main function SamVerschueren/listr#43

Closed

sindresorhus mentioned this pull request Jan 30, 2017

Support reinstalling node_modules with yarn? #98

Closed

SamVerschueren requested changes Feb 19, 2017

View reviewed changes

Add Yarn support

1561fbf

SamVerschueren requested changes Mar 2, 2017

View reviewed changes

SamVerschueren approved these changes Mar 5, 2017

View reviewed changes

sindresorhus approved these changes Mar 15, 2017

View reviewed changes

sindresorhus merged commit 6b8907e into sindresorhus:master Mar 15, 2017

renovate-bot mentioned this pull request Mar 15, 2017

Update dependency np to version 2.13.0 renovatebot/renovate#135

Merged

SamVerschueren mentioned this pull request Mar 16, 2017

Yarn updates lockfile on dependency mismatch #134

Closed

Use Yarn when available #114

Use Yarn when available #114

Conversation

gillchristian commented Dec 11, 2016 • edited Loading

SamVerschueren commented Dec 11, 2016

gillchristian commented Dec 11, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gillchristian commented Dec 12, 2016

Choose a reason for hiding this comment

sindresorhus commented Dec 12, 2016

SamVerschueren commented Dec 13, 2016

gillchristian commented Dec 13, 2016

SamVerschueren commented Dec 13, 2016 • edited Loading

Choose a reason for hiding this comment

gillchristian Dec 13, 2016 • edited Loading

Choose a reason for hiding this comment

SamVerschueren left a comment

Choose a reason for hiding this comment

gillchristian commented Dec 15, 2016

SamVerschueren commented Dec 16, 2016

sindresorhus commented Dec 16, 2016

gillchristian commented Dec 17, 2016

sindresorhus commented Jan 5, 2017

gillchristian commented Jan 5, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Solution 1

Solution 2

Solution 3

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SamVerschueren Jan 27, 2017 • edited Loading

Choose a reason for hiding this comment

gillchristian Jan 27, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sindresorhus commented Jan 7, 2017

jonathanrdelgado commented Feb 2, 2017

gillchristian commented Feb 2, 2017

jonathanrdelgado commented Feb 2, 2017 • edited Loading

SamVerschueren commented Feb 3, 2017 • edited Loading

gillchristian commented Feb 3, 2017

SamVerschueren commented Feb 3, 2017

jonathanrdelgado commented Feb 3, 2017

gillchristian commented Feb 3, 2017 • edited Loading

SamVerschueren commented Feb 3, 2017

jonathanrdelgado commented Feb 3, 2017

jonathanrdelgado commented Feb 7, 2017

sindresorhus commented Feb 18, 2017

SamVerschueren left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonathanrdelgado commented Mar 2, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gillchristian commented Dec 11, 2016 •

edited

Loading

gillchristian commented Dec 11, 2016 •

edited

Loading

SamVerschueren commented Dec 13, 2016 •

edited

Loading

gillchristian Dec 13, 2016 •

edited

Loading

SamVerschueren Jan 27, 2017 •

edited

Loading

gillchristian Jan 27, 2017 •

edited

Loading

jonathanrdelgado commented Feb 2, 2017 •

edited

Loading

SamVerschueren commented Feb 3, 2017 •

edited

Loading

gillchristian commented Feb 3, 2017 •

edited

Loading

rarkins commented Mar 16, 2017 •

edited

Loading