Skip to content
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 an optional settings to use Yarn to run Husky #511

Merged
merged 2 commits into from
Jun 26, 2019

Conversation

arcanis
Copy link
Contributor

@arcanis arcanis commented Jun 25, 2019

This fix has multiple purposes that improve the compatibility with Yarn at little cost:

  • First, it ensures that the Husky command will run with the same pipeline as the one used by Husky's users when they run their scripts. It previously wasn't the case, because Husky was using run-node to "detect" the version of Node to use whereas Yarn users were using yarn run [...] (which enforces the Node version to be the same one as the one used to run Yarn itself).

  • Second, starting from Yarn 2 we're looking to keep packages inside their tarballs as much as possible. In the context of run-node this causes problems, because run-node is a shellscript and can only be executed when unpacked. Using yarn husky-run avoids the issue altogether.

  • Third, when working with PnP environments, if we call the Node script manually, then we need to inject the PnP hook so that Husky knows how to load its dependencies (since they aren't in the node_modules folder anymore). Using yarn run makes this process transparent: it will inject the hook when running under PnP, and won't do it otherwise, and the Husky script won't have to know anything about it.

  • Four, I'd like to make it possible to track which scripts and binary are used in an application (through Yarn's new plugin system). Directly calling the Husky script wouldn't allow that, but going through yarn run would.

I guess later we can see whether it would make sense to enable HUSKY_USE_YARN by default in some circumstances, but for now I think it's fine if we keep it behind a variable that must be set through a repository-local rcfile (cf #510).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants