Add customRulePackages config option

[aldeed]

This is not quite what I proposed in #217 . Adding full extends proved a bit tricky so I concentrated on the most important thing: ability to distribute custom rules in an NPM package.

Added customRulePackages config option. It works like customRulePaths except you list NPM package names. It assumes that the named exports from each package's main entry file are each rules. You have to npm/yarn install any packages you list.

Testing

1. npm link or yarn link this branch into your project that uses graphql-schema-linter
2. Create a folder gqlsl-custom-rules in node_modules in the project
3. Add index.js file in that folder and export at least one rule from it
4. Add customRulePackages: ["gqlsl-custom-rules"] in your graphql-schema-linter config file for the project
5. Add the custom rules to rules list in your graphql-schema-linter config file for the project. Must match the name of the export.
6. Run schema linting and check that you don't get any warnings about missing rules.

Notes

The relative_module_resolver.js file I added is from https://github.com/eslint/eslint/blob/master/lib/shared/relative-module-resolver.js. Both packages are MIT licensed so this should be fine.

Not ready to merge yet. I will add documentation after the questions below are answered.

Questions

• Does this implementation seem good?
• I added the new option to the config resolver but not to the CLI command options. Should it be added to CLI, too?
• Unsure how best to write tests for this. Should I build a whole project in a temp dir and "install" a fake package in node_modules and then programmatically run the check?

[cjoudrey]

@aldeed I'm sorry for the late reply. I took a look at the PR when you first opened it and seemingly forgot to submit the review so it's been in draft since then. 🤦

Does this implementation seem good?

Yeah, looks good to me. 😄

I added the new option to the config resolver but not to the CLI command options. Should it be added to CLI, too?

Might be a good idea for consistency.

Unsure how best to write tests for this. Should I build a whole project in a temp dir and "install" a fake package in node_modules and then programmatically run the check?

That's a good question. 🤔 I think what you suggested sounds good to me. We don't necessarily need to try to make this work with the existing test structure. I wouldn't mind just adding it as another step in .travis.yml. I added a few high-level integration tests like this already.

graphql-schema-linter/.travis.yml

Lines 11 to 12 in bc080a4

	- node lib/cli.js test/fixtures/valid.graphql
	- cat test/fixtures/valid.graphql | node lib/cli.js --stdin

In other words, feel free to create a separate file for this if it makes things easier, maybe a shell (or JS) script that we execute there.

[cjoudrey]

Ohhhh, that's interesting. I hadn't even considered that. 🤔

Btw did the path you are passing need to be a file and not a folder? In other words, the __placeholder__.js was required and is okay if it does not actually exist?

[aldeed]

@cjoudrey I actually borrowed this bit of code from the eslint packages: https://github.com/eslint/eslint/blob/a47770706ac59633dcd73e886d1a7282b324ee06/lib/init/config-initializer.js#L350

I actually don't know if a folder would work, but they probably added the placeholder for a reason? 😄If I remember when I'm finishing this PR, I'll see if it works with just the CWD.

[aldeed]

@cjoudrey That all sounds good. I'll finish this as soon as I get a chance.

[mcwoodle]

Any update on this? I was looking for similar functionality.

[aldeed]

@mcwoodle Honestly completely forgot about this, but I can put it back on the to-do list.

[bcole]

+1, this would be a useful feature for us! To have a central location of rules that all our subgraphs can rely on.