Relative stdin-filename breaks my plugin

[benmosher]

Hello,

I do some relative file path resolution in my plugin (benmosher/eslint-plugin-import) to statically analyze ES2015 import syntax.

Recent changes to send a relative file path via --stdin-filename breaks this resolution. I attempted to use path.join(process.cwd(), context.getFilename()) but the relative path is not relative to the eslint working directory.

It is not clear to me why the relative path change was made in linter.py, so I don't know what the next step is. I'd like to be more robust about paths within my plugin, but in general, running eslint directly seems to provide the absolute path via context.getFilename().

[roadhump]

Hello,

see #49 for solution

[benmosher]

Ah, cool. That fixes it, thanks.

[benmosher]

Out of curiosity: is the relative --stdin-filename still necessary now that eslint v0.21.2 has been released with your PR merged? (I don't really understand the mechanisms involved.)

[roadhump]

ESLint matches ignore patterns by minimatch. node_modules/ in .eslintignore will match node_modules/file , but not /proj/node_modules/file (it should be **/node_modules/). I've tried to make it work the more common first way.

[IanVS]

We are using both an .eslintignore and eslint-plugin-import. If we use "args": ["--stdin-filename", "@"] as suggested in #49, the .eslintignore does not work properly, but if we don't use that option, eslint-plugin-import is broken.

Is this a catch-22, or is there something which can be done to make this work correctly? I also use linter-eslint for Atom, and it can handle these both successfully.

[benmosher]

I think I fixed this in the latest Node resolver. Need to publish still. I will let you know when I have (maybe later today?).

--Ben

On Dec 8, 2015, at 09:53, Ian VanSchooten <[email protected]mailto:[email protected]> wrote:

We are using both an .eslintignore and eslint-plugin-import. If we use "args": ["--stdin-filename", "@"] as suggested in #49#49, the .eslintignore does not work properly, but if we don't use that option, eslint-plugin-import is broken.

Is this a catch-22, or is there something which can be done to make this work correctly? I also use linter-eslinthttps://github.com/AtomLinter/linter-eslint for Atom, and it can handle these both successfully.

Reply to this email directly or view it on GitHubhttps://github.com//issues/58#issuecomment-162905615.

[benmosher]

I am debugging my attempt at a fix from inside the plugin. No dice so far.

Note: could the working directory be set to the base of the --stdin-filename? Then I could properly join against the CWD with path.resolve. This solves a similar problem when running inside the ESLInt Webpack loader. (eslint-loader)

[benmosher]

FWIW, once eslint/eslint#3948 is merged (looks like ESLint 2.0), I think the original full path will support both the plugin and .eslintignore.

[benmosher]

Actually, after digging around a bit I've just discovered the chdir setting for SublimeLinter, allows control of the CWD where the linter process is executed.

Updated my Sublime project to

{
    "folders":
    [
        {
            "folder_exclude_patterns":
            [
                "node_modules",
                "bower_components",
                "private_modules"
            ],
            "follow_symlinks": true,
            "path": "code"
        }
    ],
    "SublimeLinter":
    {
        "linters":
        {
            "eslint":
            {
                "chdir": "${project}/code"
            }
        }
    }
}

...and that seems to work. I can't speak for .eslintignore, but I suspect it will work as well?

Note that my project file is in code's parent directory; were it (or a .sublimelinterrc) in the same folder as code, I think the right chdir value would just be ${project}. YMMV?