fix: normalize cwd passed to ESLint/FlatESLint constructor

[mdjermanovic]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[x] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

Fixes #17042

What changes did you make? (Give an overview)

Updated ESLint and FlatESLint constructors to path.normalize() given cwd right away when processing options.

This fixes bug #17042 for the ESLint class (the same bug did not exist for the FLatESLint class) and also ensures that rules and formatters always get normalized cwd.

Is there anything you'd like reviewers to focus on?

[nzakas]

LGTM. Would like someone else to review before merging.

[fasttime]

After this change, a custom formatter will be passed a normalized cwd instead of what was originally specified. A naively designed unit test could start failing because of the new behavior. Is this acceptable for a non-breaking fix?

[mdjermanovic]

After this change, a custom formatter will be passed a normalized cwd instead of what was originally specified. A naively designed unit test could start failing because of the new behavior. Is this acceptable for a non-breaking fix?

I think it's acceptable for a non-breaking fix. We don't guarantee that the data passed to formatters will remain exactly the same, and that looks more like an integration test than a unit test.

[nzakas]

I think it's acceptable for a non-breaking fix. We don't guarantee that the data passed to formatters will remain exactly the same, and that looks more like an integration test than a unit test.

Agreed.

[fasttime]

LGTM. Thanks!