`standard.lintFiles()` doesn't use `process.cwd()`

[regseb]

`standard.lintFiles()` doesn't use `process.cwd()`

[regseb]

Want to open a PR for that?

I opened the pull request standard/standard-engine#329.

[rhettjay]

Thanks for taking the time to submit the PR. I must apologize, I'm somewhat confused on the use case you reference in the PR. It feels like you may want to investigate spawning a child process per linter instead of changing the process dir. As @wesleytodd mentioned, adjusting the cwd in flight can get hairy because so many things can rely on it.

Nonetheless, your issue as described is currently possible by simply adjusting the cwd property on standard before linting the files. Which utilizing your sample code looks like the following:

import fs from "node:fs/promises";
import process from "node:process";
import standard from "standard";

console.log(await fs.readFile("foo/bar.js", "utf8"));
console.log(await standard.lintFiles(["foo/bar.js"]));

process.chdir("foo");
console.log(await fs.readFile("bar.js", "utf8"));
standard.cwd = process.cwd()
console.log(await standard.lintFiles(["bar.js"]));

Tested locally with node 20 and standard 17 on an intel macOS and it worked fine for me.

[wesleytodd]

Looks like it might be relatively simple to add cwd = process.cwd() in lib/options? Want to open a PR for that?

[regseb]

I worked around the bug with this code (and the directory change works):

const results = await standard.lintFiles(["bar.js"], {                       
    cwd: process.cwd(),                                                  
}); 

I've opened this issue and a PR to fix the problem in Standard so that everyone can benefit from it. And also because it's strange to pass the default value; you feel like removing it because it seems useless.

If you don't want to correct this problem, I think the documentation should be changed to reflect reality.

[rhettjay]

Confirmed. I didn't understand then. The workaround (what I thought you were implying was not working properly) is what I believe should be done in this case.

it's strange to pass the default value; you feel like removing it because it seems useless.

I concede your point: we should not require a user to specify a default property. On the other hand, I remain convinced it's better practice to avoid defaulting to the process at function call time instead setting it when the class constructor is called. The existing code allows for this. In fact, I believe we would find the majority of users are not using standard in this manner anyway, but are executing it via the cli or some manner of integration. For those reasons, I'm -1 on accepting the adjustment and +1 on correcting the documentation.

I'll submit a preliminary PR, but allow time for you or others to weigh in if you feel I've missed something. Thanks again for raising this issue.