validation only triggers if package.json is in workspace root

[missinglink]

Here's what I did

settings.json
{
    "standard.enable": true,
    "standard.usePackageJson": true,
    "standard.autoFixOnSave": true,
    "standard.enableGlobally": false,
    "standard.validate": [
        "javascript",
        "javascriptreact"
    ]
}

package.json
{
  "devDependencies": {
    "standard": "^17.1.0"
  }
}

Create a two-level directory structure: parent -> example

What I expected to happen

I expected validation to be enabled when my package.json was not in the root of the Workspace.

What seems to have happened

It works if I remove the parent directory such that the package.json is now in the Workspace root.
It doesn't work when the package.json is nested below the root.

ie. this directory layout works:

Explanation

This is the coded behaviour here:

vscode-standard/client/src/extension.ts

Lines 226 to 232 in 7736794

	if (
	!isEnabledGlobally &&
	usePackageJson &&
	Workspace.workspaceFolders?.length === 1
	) {
	const workspacePath = Workspace.workspaceFolders[0].uri.fsPath
	const packageJsonPath = path.join(workspacePath, 'package.json')

Possible Workaround

Enabling "standard.enableGlobally": true allows the two-level directory structure to be validated.

This isn't acceptable in my situation as, even though I have only one top-level directory, only some of my second-level directories follow this style guide and I can't enable it for all those directories.

Suggested Fix

Instead of assuming that the package.json file is in the root of the Workspace it might be better to 'walk down' the textDocument.path until a directory with a package.json file is found (in the same way npm walks down until it finds the module root).

Closing notes

There is some code which mandates that workspace only has one top-level directory (Workspace.workspaceFolders?.length === 1), this is actually unrelated to this issue, since I do only have one top-level directory in my example.

[missinglink]

related #263 cc/ @theoludwig

[bigbn]

Unfortunately, this remake of the extension was completely broken. After a year of waiting for a fix for this problem, nothing happened, and it also looks abandoned.

For those who looking a solution and not just workaround:

1. Totally remove standard extension and its options from settings.

2. Install ESLint microsoft's plugin (dbaeumer.vscode-eslint).

3. Option "eslint.workingDirectories": ["subdir"] for this extension will work as it was in early standard extension before remake. This is what we want, this is our requirement.

4. npm install --save-dev eslint-config-standard

5. Create file .eslintrc.json inside subdir. This is example of my config:

    {    
        "extends": [
            "standard",
            "plugin:react/recommended"
        ],  
        "parser": "@babel/eslint-parser",  
        "parserOptions": {},    
        "plugins": ["flowtype", "react"]   
    }
   

the key is the extends feauture.
6. Enable eslint as formatter and linter in user or workspace settings:

    {
        "eslint.debug": true,
        "javascript.validate.enable": false,
        "eslint.format.enable": true,
        "eslint.lintTask.enable": true,
        "eslint.workingDirectories": ["subdir"],
        "editor.codeActionsOnSave": {
            "source.fixAll.eslint": "always"
        },
        "[javascript]": {
            "editor.defaultFormatter": "dbaeumer.vscode-eslint"
        }
    }

debug will help you if something goes wrong. There are lot of messages that could help.

Thats all. Now you can continue to write your nice code without pain as you are used to.

[voxpelli]

@bigbn This is a reason why we're trying to avoid creating an extension for neostandard: neostandard/neostandard#4

Unfortunately ESLint has no interest in making it easier to provide a standard style tool, so it will still have to be a bit rough on either CLI or extension side: eslint/eslint#18800