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
shareable config #245
Comments
Hi @travi, I like the idea :) (I think there's another issue suggesting something similar) |
sorry about missing an existing issue. i guess my search terms missed the mark. as far as the hooks we would want to share, we are pretty solid on
the others we are still trying to figure out exactly where we want to land, which leads to the desire to experiement, but consistently, that i mentioned earlier:
our builds are pretty fast, but if you make a commit (runs |
+1 would be beneficial to have a |
in case it is helpful, i ran across a library called ex-config that is meant to work with |
In my case we provide a
Although I can use a It could be very useful if husky can provide a Node API which initialize all things above, look like:
and within const husky = require('husky'); // This can locate husky package correctly
// cwd() will be the root of project, not `fe-tools` package directory,
// update package.json and add git hooks here,
// husky's location can be resolved using `require.resolve` within husky package itself
husky.initialize(process.cwd()); |
any chance this will make the cut for v1.0? |
Any update on this? |
Would you like some help with this issue? |
Our use case is the same as @otakustay, so I think it would also be very beneficial to add the eslint-style // .huskyrc.js
module.exports = require('node_modules/my-private-config-pkg/husky'); // node_modules/my-private-config-pkg/husky.json
{
"hooks": { ... }
} If you want to "extend" the original configuration then you can merge it with another object that overwrites the keys you want to override. |
hookIsDefined () {
grep -qs $hookName \
package.json \
.huskyrc \
.huskyrc.json \
.huskyrc.yaml \
.huskyrc.yml \
.huskyrc.js \
husky.config.js
}
# Skip fast if hookName is not defined
if ! hookIsDefined; then
debug "$hookName config not found, skipping hook"
exit 0
fi If hook name is not contained directly within one of acceptable config locations hook won't run at all... |
In my case what I got common is the .huskyrc file and I would like to somehow extend it in my project so I can do more things in the hooks that what is established in the common husky config... Am I wrong? |
Added a section to the docs explaining one way to share hooks with the new husky. |
Hmm do you mean this section? It shows how to create a shareable config but not sure if I understand how I'd use it in node project. I think this could be better achieved by allowing the husky config file be its own module with a |
The mentioned solution is terrible. |
@typicode any word on the comments above? |
Am I crazy or "this section" doesn't exist? |
@eliasjnior nope, you're not crazy. It appears to have been removed. |
So this issue should be reopened. I was trying to standardize some projects like I do with ESLint rules, using |
have you considered a shareable config? i find myself using the same scripts across almost all of my node projects, so it would be great to be able to extend a config that i publish as a node package as a starting point.
ideally, support would look similar to those available from
with the upcoming support for config files through cosmicconfig, adding support for extending other files seems like a very natural fit.
i like the convention of those listed above where a package named
husky-config-travi
could be used as"extends": "travi"
, which would apply the config from the dependency, but allow additional config to define more information or override config from the shareable config.does supporting something along these lines seem reasonable? i think it would be a huge help in my personal projects and those for my team.
as an example use case, we just had a conversation about a change we want to try out, but trying it consistently across all projects will require updating each individually (and possibly changing them all back if the change is one we decide we dont like). defining the change in a shareable config would limit the actual definition to a single place and only require us to update that package through npm (which we already automate with greenkeeper and greenkeeper-keeper).
The text was updated successfully, but these errors were encountered: