feat: Resolve a npm package passed as --config

[cameronhunter]

feat: Resolve a npm package passed as --config

This PR enables a npm package to be passed to the command line --config parameter and will be resolved by lint-staged.

Example:

Say you have a npm package my-tools-config/lint-staged, your application can now depend on the configuration package and lint-staged allowing:

lint-staged --config my-tools-config/lint-staged

[codecov]

Codecov Report

Merging #464 into master will increase coverage by 0.02%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #464      +/-   ##
==========================================
+ Coverage   98.72%   98.74%   +0.02%     
==========================================
  Files          12       12              
  Lines         235      239       +4     
  Branches       28       28              
==========================================
+ Hits          232      236       +4     
  Misses          3        3

Impacted Files	Coverage Δ
src/index.js	92.5% <100%> (+0.83%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3d0ccb2...4a705f8. Read the comment docs.

[okonet]

I’m wondering what are you trying to solve? 🚫💩 Lint-staged is meant to run on pre-commit so I’m not sure why it needs to be exposed to Node.

[cameronhunter]

I understand your concern. We work on multiple applications using the same toolchain, it's a similar(-ish) setup to how Create React App encapsulates tools. Due to the reuse of our toolchain we keep our configuration files in a private npm module, tool-config.

Our pre-commit hook looks like:

#!/usr/bin/env node

const lintStaged = require('lint-staged');
const config = require('tool-config/lint-staged');

lintStaged(config);

This allows our configuration to be anywhere on the node resolution path, removing an absolute file path (that we had previously) and removes any breakage that would happen in a yarn monorepo (due to module hoisting).

[okonet]

I’m just wondering is similar is possible with just using node’s resolve inside that file? I’m not against this change but before we go this route is like to check if it’s absolutely necessary. Also I’d like to avoid breaking changes if possible. Thoughts?

[cameronhunter]

I guess we could use require.resolve on the --config param within lint-staged. It would allow us to change our pre-commit hook to:

#!/usr/bin/sh
$(npm bin)/lint-staged --config 'tools-config/lint-staged'

With regards to the break change: I was perhaps being overly cautious. I reordered the params on the internal interface which was never explicitly exposed (via package.json's main param). It would be a breaking change to people deep requiring into the module, e.g.:

const lintStaged = require('lint-staged/src/index');

But if they're doing that then this PR would be what they'd want to update to anyway.

[okonet]

So I’m still not sure if this PR is needed :) can you confirm you can aichive this without it? Or it is still needed for your case?

[cameronhunter]

Hi @okonet, I've updated the PR. I'm now using require.resolve on the --config parameter which enables a npm package to be used as config (as well as a file path as before).

This is no longer a breaking change and would only require a minor version bump.

[okonet]

Can you please add a test for it?

[cameronhunter]

Test added

[sudo-suhas]

Shouldn't there be a mock implementation as well? Also, there should be an assertion to check that the specified package was resolved and required.

[cameronhunter]

There is... the __mocks__/my-lint-staged-config directory is the mock implementation. The mock implementation contains the config { '*': 'mytask' } which is included in the snapshot providing an end-to-end assertion that the package was required and resolved.

[sudo-suhas]

Ah, yes I see that now. My bad.

Clarified by @cameronhunter

[sudo-suhas]

LGTM

[okonet]

Thanks for working on this!

[cameronhunter]

Thanks for taking the time to review this, we ended up with a much cleaner solution than what I initially proposed. Can you speak to when this change will be published?

[sudo-suhas]

We use semantic-release so this has been released already via v7.2.0