Vetur: Template Interpolation Issue - First letter not recognized in event variable assignment

[xon52]

Info

• Platform: Win
• Vetur version: 0.21.0
• VS Code version: 1.35.0

Problem

When entering a data property into an event, it ignores the first letter and so persistently reports that the property does not exist. This error can be removed by surrounding the statement in curly brackets, but that creates a bigger Vue error.

Reproducible Case

Turn Template Interpolation Service on and write the following code:

<template>
    <span @click="eg = true">Test</span>
</template>

<script>
export default {
    data() {
        return {
            eg: false
        }
    }
}
</script>

[ktsn]

I just copied & pasted your reproducible case but cannot reproduce on my local. Could you provide full contained repro by cloning and modifying Veturpack?

[xon52]

So using a Veturpack repo I could not reproduce the issue above. Then I tried my example above again and I didn't have the issue anymore. Then I tried everything I could do to get that error in a new project and couldn't... So probably another interaction issue. Not really sure how else to test.

However, incase this does come up later, I have made a couple more observations.

The issue above can be removed in a couple ways:

1. If the @click property is modified using Event Modifiers
2. If there are multiple properties for the element, and you include one or more on the same line as the @click:
   

Both are really strange, so I hope you can see a link between those observations and the vetur code I don't!

[ktsn]

That's weird... Even there is multi-lined attribute element, its v-on handler works fine for me.

By the way, what can you see when you execute a command Vetur: show corresponding virtual file and source map? (please copy and paste the result)

[xon52]

OK I found the command vetur.showCorrespondingVirtualFile... But just for fun let's pretend I don't know how to run that command - how would I do that?

[ktsn]

Open command palette (by Ctrl + Shif + P), and type search word (e.g. vetur virtual). Then the command will be suggested on Editor, then click it or press enter.

[xon52]

Thanks. Unfortunately, doesn't say much:

[ekulabuhov]

Hey! I've a similar issue. Both SourceMap and compiled version shows broken variable name:

Is there anything else I could do to help diagnose the problem?

[imdbere]

I have the exact same problem. Would be happy to help if there is any additional information i could provide

[ktsn]

This may be solved by this PR #1335

[rille111]

Still same problem. Using vuetify. Doesnt seem to be the same problems in other projects, weirdly enough.

[chartinger]

I have the same problem. Running test:int (Windows 10, node 12.13.1, yarn 1.21.1, VSCode used by testrunner 1.41.1) on commit 26ab1b04084f93909c95563e6f367796b2589ef0 correctly results in a failed test in 1) Shows template diagnostics for v-on.vue:

1 failing                                                                                                  
1) Should find template-diagnostics in <template> region                                                   
     Shows template diagnostics for v-on.vue:                                                              

    AssertionError [ERR_ASSERTION]: Expected diagnostics length is not same as actual diagnostics one      
    + expected - actual                                                                                    

    -4                                                                                                     
    +7 

The 3 extra errors seem to be the "off-by-first character" errors. (They are shown when opening the file with the my "normal" VSCode)

Edit: expected and actual are in the wrong order (https://github.com/vuejs/vetur/blob/master/test/interpolation/diagnostics/helper.ts#L17)

[chartinger]

The problem is related to the configured line endings. Switching VS Code to LF and it works as expected, CRLF results in the error.

[octref]

I got a repro while trying to reenable Windows CI: https://dev.azure.com/octref/Vetur/_build/results?buildId=960&view=logs&j=022b0a5d-2698-5f72-7610-a845972a8b4c&t=af0b5d72-a8ff-57fd-7b7c-b5fc756da7a6

[octref]

https://github.com/mysticatea/vue-eslint-parser/issues/59 is the upstream issue. expression is off by 1 when using CRLF.

I can only suggest using LF now, I don't have a whole afternoon to dive into the eslint parser...

[3nuc]

I tried to force LF in a project I was setting up at work and it's problematic. Mainly because Git will by default change line endings to CRLF on Windows even if they were saved as LF during cloning the repo.

I haven't been able to override these Git settings using a config file commited to the repo (eg. .gitattributes). It's supposedly possible to do git config --global core.eol lf but telling every developer after cloning the project "yeah just do git config --global core.eol lf or else prettier will be complaining to you" is a pain

[octref]

Waiting for the upstream PR: https://github.com/mysticatea/vue-eslint-parser/pull/74

[lanyizi]

Before upstream fixes this, another workaround could be wrapping the assignment in a function.
This is useful when you do want to keep each event on its own line to keep readability (or if your auto formatter does this)
The insertion of code (which causes this issue) only happens when the attribute value is a statement, and vue-eslint-parser will try to insert void function($event){ and then recalculate (a presumably wrong) offset, which will then cause the issue.

If you don't want to write a dedicated vue method for your statement, you can wrap your statement inside a lambda, for example

<span
  @click="() => eg = false"
/>

[stevenarm]

I have this issue as well. Would be happy to help or post code if needed. I am Vetur v0.28.0 and VS Code 1.49.3

[octref]

I'll merge https://github.com/mysticatea/vue-eslint-parser/pull/74 to my branch and publish it, so I can depend on it.

@ota-meshi Thanks for your work! Do you think we can keep a fork active together until @mysticatea is less busy and can get back to vue-eslint-parser?

[octref]

Does this still repro for you? I cannot repro in latest version. CI cannot detect this error as well:

https://github.com/vuejs/vetur/runs/1218328035

This file with CRLF: https://github.com/vuejs/vetur/blob/1319/test/interpolation/fixture/diagnostics/crlf/crlf.vue

Triggers this error:

[
  {
    "severity": "Error",
    "message": "Property 'egg' does not exist on type 'CombinedVueInstance<Record<never, any> & Vue, object, object, object, Record<never, any>>'.",
    "range": [
      {
        "line": 1,
        "character": 16
      },
      {
        "line": 1,
        "character": 19
      }
    ],
    "source": "Vetur",
    "code": 2339
  }
]

[ota-meshi]

Do you think we can keep a fork active together

@octref Sure.
And I'm actually contacting him via Discord now and waiting for his reply.

[ota-meshi]

I was able to contact him.
Then, I merged and released a fix for the CRLF issue.

https://www.npmjs.com/package/vue-eslint-parser/v/7.1.1
https://github.com/mysticatea/vue-eslint-parser/releases/tag/v7.1.1

This is my first release so please let me know if you have any issues.

[octref]

@ota-meshi Thanks a ton! I pulled it in and it works great during my test. Thanks for reviving vue-eslint-parser.

[bestickley]

I'm still having an issue with this.

• Vetur 0.28.0
  Related node modules:
  "@typescript-eslint/eslint-plugin": "^4.4.1",
  "@typescript-eslint/parser": "^4.4.1",
  "@vue/cli-plugin-babel": "^4.5.7",
  "@vue/cli-plugin-eslint": "^4.5.7",
  "@vue/cli-plugin-typescript": "^4.5.7",
  "@vue/cli-plugin-unit-jest": "^4.5.7",
  "@vue/cli-service": "^4.5.7",
  "@vue/eslint-config-prettier": "^6.0.0",
  "@vue/eslint-config-typescript": "^7.0.0",
  "@vue/test-utils": "^1.1.0",
  "eslint": "^7.11.0",
  "eslint-plugin-prettier": "^3.1.4",
  "eslint-plugin-vue": "^7.0.1",

[yoyo930021]

I'm still having an issue with this.

• Vetur 0.28.0
  Related node modules:
  "@typescript-eslint/eslint-plugin": "^4.4.1",
  "@typescript-eslint/parser": "^4.4.1",
  "@vue/cli-plugin-babel": "^4.5.7",
  "@vue/cli-plugin-eslint": "^4.5.7",
  "@vue/cli-plugin-typescript": "^4.5.7",
  "@vue/cli-plugin-unit-jest": "^4.5.7",
  "@vue/cli-service": "^4.5.7",
  "@vue/eslint-config-prettier": "^6.0.0",
  "@vue/eslint-config-typescript": "^7.0.0",
  "@vue/test-utils": "^1.1.0",
  "eslint": "^7.11.0",
  "eslint-plugin-prettier": "^3.1.4",
  "eslint-plugin-vue": "^7.0.1",

This fix is not release now.

[stvoidmain]

Before upstream fixes this, another workaround could be wrapping the assignment in a function.
This is useful when you do want to keep each event on its own line to keep readability (or if your auto formatter does this)
The insertion of code (which causes this issue) only happens when the attribute value is a statement, and vue-eslint-parser will try to insert void function($event){ and then recalculate (a presumably wrong) offset, which will then cause the issue.

If you don't want to write a dedicated vue method for your statement, you can wrap your statement inside a lambda, for example

<span
  @click="() => eg = false"
/>

Using a lambda work nicely to avoid the error and keep readability, thanks.