[Docs Bug] Custom, sharable configuration with private, scoped repos
downzer0 opened this issue · comments
📚 Request documentation enhancements
Description
Need documentation on how to use configuration from a scoped package (e.g., @my-org/webhint-configuration-my-custom-conf)
Details
The documentation has examples for using @hint maintained configurations, or custom configurations prefixed with "webhint-configuration-", both of which work. However I need shared configuration from a scoped package name and this does not seem to work. Unsure if it's a bug, a missing feature, or something I'm doing wrong that isn't documented.
Thanks!
Interesting, there's at least an explicit test case for using a connector from a scoped package (though nothing specific to configurations):
Any chance you could share a small sample project demonstrating your setup?
Sure, hopefully this is helpful despite the intentional vagueness:
Shared configuration repo
// package.json
{
"name": "@my-org/webhint-configuration-my-org",
"main": "index.json",
"dependencies": {
"hint": "^6.1.11"
}
}
// index.json
{
"connector": "local",
"formatters": ["stylish"],
"parsers": ["typescript", "html"],
"hints": { // various hints here }
}
Consumer repo
// package.json
{
"name": "some-consumer",
"dependencies": {
"@my-org/webhint-configuration-my-org": "^1.0.0",
"hint": "^6.1.11"
}
}
// .hintrc
{
"extends": ["@my-org/webhint-configuration-my-org"]
}
If I test this unscoped, it works, provided I've got the "webhint-configuration-" prefix on the package name. If I add a scope, I get the following:
AnalyzerError: Invalid configuration. Resource @my-org/webhint-configuration-my-org not found.
This leads me to believe the code is looking for exactly @hint/
or webhint-configuration-
as the package prefix.
One additional finding: scoped naming conventions such as @my-org/webhint-configuration-my-org work when using the command line such as:
package.json
...
"scripts": {
"hint": "hint -c .hintrc"
}
.hintrc
{
"extends": ["./node_modules/@my-org/webhint-configuration-my-org"]
}
But I have to specify the path including node_modules.
This however does not work with the VS Code extension which doesn't seem to use the same .hintrc and throws an error "Unable to start webhint".
Thanks @downzer0!
Digging into this it actually worked for me if webhint was installed in the local project, but not if it wasn't (e.g. using npx hint ...
or the VS Code extension's shared version of hint
). Definitely seems like a resource loader bug of some sort, so probably somewhere it the load-resource
helper (which honestly is likely overdue for a re-write):
I still haven't spotted exactly why this isn't getting picked up, though. If @molant or someone else has an idea, I'd love to hear it.
I don't remember where hint
is installed when pulled from the VS Code extension, but could it be a path resolution error because it is in a different location than the custom configuration package?
If that's the case we have 2 options:
- update
resource-loader
to take into account this (don't know how much of a pandora's box that would be) - update the docs to say that if custom configurations are needed, then the
hint
package needs to be installed in the project
I have this working in the CLI, which should work for us. Thank you both for investigating. You may close this one out.
Thank you all for working together on resolving this. Closing the issue now.