There was PR by @j-f1 with accessibility, export and static reported as errors #51, and i think we should not add unsupported properties to ast. this is just going to make ast unreadable.

we already have diagnostics in project.

Can we not just enable TS1070 as part of this PR?

we can but i was not sure if you want to xd

Cool, yeah I think it makes sense based on all the precedent we have - it is not breaking by default, because you still have to opt into the diagnostics, even after we included them

ok

we are keeping fields for accessibility, export and static ?

Hmm, I'm a bit confused now about the expected issue - nothing in the snapshot has changed after you have enabled the check?

now you can see changes in ast

I mean when we enable a new semantic check, we should be seeing a new diff in the semantic-errors snapshot. There isn't any change as a result of enabling the check here, which means we don't have coverage for it currently, right?

its part of interface-property-modifiers but looks like there is way more errors there, and we are catching different one now

there are 1070, 1071, 1246, 2374, 1024, 2411

i think we should should split this test to smaller one with separated errors :>

Ok I see, that's the same as I had here:

/**
     * There are number of things that can be reported in this file, so it's not great
     * for comparison purposes.
     *
     * Nevertheless, Babel appears to throw on syntax that TypeScript doesn't report on directly.
     *
     * TODO: Investigate in more depth, potentially split up different parts of the interface
     */
'interface-with-all-property-types', // babel parse errors

We could leave the diagnostics piece out of this PR for now then?

kk, i'm going to split this to smaller separated errors in separated PR

@JamesHenry i added PR with test cases for this #113

Merged!

🎉 This PR is included in version 15.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀