Feature: Built-in linter engine - #2066
Conversation
|
Changes in this PR will be published to the following url to try(check status of TypeSpec Pull Request Try It pipeline for publish status): Website: https://cadlwebsite.z1.web.core.windows.net/prs/2066/ |
| }); | ||
| beforeEach(() => { | ||
| const runner = createTestRunner(); | ||
| ruleTester = createRuleTester(runner, requiredDocRule, "@typespec/my-linter"); |
There was a problem hiding this comment.
This differ from the linter library because now as the emitted diagnostic is fully configured within the rule there is no ref of the library anymore. (While before it was just reporting a std diagnostic).
This makes it that if we want the test to be able to check the resolved diagnostic we need to explicitly pass the library name.
There is a few options here:
- Have what we have here, a little more extra config
- Remove that parameter(or make it optional) and then the diagnostic in the test will not be prefixed by the lbirary name. Maybe just have a placeholder
code: "{library-name}:no-foo-model", - The
toEmitDiagnosticsactually doesn't expect the resolve diagnostic but just what the rule pass so you'd have that below
ruleTester.expect(`model Foo {}`).toEmitDiagnostics({
messageId: "default"
});
Disadantage of this is we don't get to test message interpolation
For reference that's what eslint does but Im not sure they have the same interpolation system as us.
David Wilson (daviwil)
left a comment
There was a problem hiding this comment.
Looks great!
Fix #1996
Implementation for the linter engine
tspconfig.yaml