Add physicalFilename option into rule tester

[JounQin]

@snitin315 @nzakas @mdjermanovic

I find physicalFilename is not available in ValidTestCase, so it makes testing cases for virtual filename unavailable, should that be supported?

Before context.getPhysicalFilename, I have a custom util getPhysicalFilename and a test case like:

ruleTester.run('remark', remark, {
  valid: [
    {
      code: '<header>Header2</header>',
      parser,
      parserOptions,
      filename: path.resolve(__filename, '0-fake.mdx'), // virtual filename
    },
  ],
})

But when I migrate to context.getPhysicalFilename, it results context.getPhysicalFilename() === filename, it is not correct, so maybe a new physicalFilename option is required for this case:

ruleTester.run('remark', remark, {
  valid: [
    {
      code: '<header>Header2</header>',
      parser,
      parserOptions,
      physicalFilename: __filename,
      filename: path.resolve(__filename, '0-fake.mdx'), // virtual filename
    },
  ],
})

Originally posted by @JounQin in #14616 (comment)

[nzakas]

That seems reasonable to me. @eslint/eslint-tsc thoughts?

[mdjermanovic]

RuleTester uses Linter API. physicalFilename is not an option on the API. Values returned by context.getFilename() and context.getPhysicalFilename() are calculated from the passed filename and the output of processors applied during the process.

I think it would make more sense to support processors in RuleTester (eslint/rfcs#31), than adding an option that would force Linter to change its internal logic and return some other value from context.getPhysicalFilename().

[nzakas]

@mdjermanovic nice catch! That makes sense to me. I completely forgot about the RFC.

[nzakas]

TSC Summary: This issue requests to add a physicalFilename option to RuleTester to help with testing code blocks. There is already an RFC for enabling processors in RuleTester (eslint/rfcs#31) that may be more appropriate.

** TSC Question:** How do we want to proceed here?

[btmills]

In the most recent TSC meeting, we agreed to go with the approach described in RFC31. I'll be picking up that RFC to update it as necessary and get it through approval.

[github-actions]

Oops! It looks like we lost track of this issue. @eslint/eslint-tsc what do we want to do here? This issue will auto-close in 7 days without an update.

[nzakas]

@btmills where are we on this?

[btmills]

It sounded like mysticatea had a couple changes planned for the existing RFC, so I left a comment inquiring what those might be before I make any changes of my own, but I haven't heard back. I'll go ahead and update it for review by the team.

[btmills]

RFC31 has been updated. Give it a look and please share any feedback!