Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[JavaScript] "meta.type" scope leaks into following comment #3774

Open
rchl opened this issue May 20, 2023 · 5 comments
Open

[JavaScript] "meta.type" scope leaks into following comment #3774

rchl opened this issue May 20, 2023 · 5 comments

Comments

@rchl
Copy link
Contributor

rchl commented May 20, 2023

What happened?

In all those 3 cases the meta.type scope from the type annotation is also applied to the following comments.

// 1
const x: string /** The production or development server. */

// 2
const x: string // The production or development server.

// 3
export interface Foo {
    a: string
    /** The resolved Nuxt configuration. */
    b: number
}

I've noticed that because I've applied custom color to meta.type with the intention of using it with my JSDoc scoping PR. Otherwise this issue might not be noticeable really.

Screenshot 2023-05-20 at 22 11 19

@Thom1729
Copy link
Collaborator

Example:

let x: string /** The production or development server. */
  | number;

In the above case, the comment is within the type expression. In Example 1, it would be possible in principle to exclude the comment from the meta scope, but that would require branching.

There are a lot of similar cases in the syntax where a meta scope may include trailing whitespace or comments. When there's an explicit ending delimiter, it should end the meta scope right away, but when the ending is ambiguous it would be a lot of hassle/extra code to do that.

@rchl
Copy link
Contributor Author

rchl commented May 20, 2023

Example 3 is really what made me file this issue. The other ones I just came up with to make it more difficult. :)

It's an unfortunate conflict with convention since such comments apply to the code below but inherit scope/style from the type annotation above.

@Thom1729
Copy link
Collaborator

Example 3 has a workaround — use explicit terminators.

export interface Foo {
    a: string;
    /** The resolved Nuxt configuration. */
    b: number;
}

@rchl
Copy link
Contributor Author

rchl commented May 20, 2023

Yeah, but some projects enforce no terminators.

@Thom1729
Copy link
Collaborator

Oof. Yeah, that's rough. Automatic semicolon insertion was a mistake and mandating it is nuts. Not sure if there's a reasonable workaround there, since relying on ASI makes everything harder to parse anyway (every tmLanguage I've seen is riddled with bugs around it).

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants