webhintio / hint

💡 A hinting engine for the web

Home Page:https://webhint.io/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[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):

name: '@example/webhint-connector-example',

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):

export const loadResource = (name: string, type: ResourceType, configurations: string[] = [], verifyVersion = false) => {

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.