0

I am using a snippet manager that dynamically creates editor files when I edit the snippet.

eg C:\Users\myUserName\AppData\Local\Temp\bXNSZWNlaXZlQnJvYWRjYXN0.javascript.snippet

I have set the language to JavaScript so I get syntax colours. Eslint throws errors on lines like:

async msReceive${1/(.*)/${1:/capitalize}/} (msMessage, msEnvelope) {

I am trying to set .eslintignore to ignore those files and cannot find a combination that works. I am restarting vscode after each change to .eslintignore

What glob pattern could I use to ignore all files in C:\Users\myUserName\AppData\Local\Temp ? The issue is relevant for other languages I have snippets for.

I also tried the /* eslint-disable */ way but that gets ignored too.

Thanks, Murray

Edit: some screen shots: enter image description here

enter image description here

The main point is if I have my .eslintignore glob correctly set surely the language association and .eslintrc.js settings should be irrelevant?

I have tried:

C:/Users/myUserName/AppData/Local/Temp/**/*

C:\\Users\\myUserName\\AppData\\Local\\Temp\\**/*

**/*.javascript.snippet
C:/Users/myUserName/AppData/Local/Temp/**
C:/Users/myUserName/AppData/Local/Temp/*
C:/Users/myUserName/AppData/Local/Temp
C:\\Users\\myUserName\\AppData\\Local\\Temp

Also, if I save a copy of the file within my workspace eg temp.javascript.snippet and keep the /* eslint-disable */ it also still lints the file and shows the same error.

Murrah
  • 1,508
  • 1
  • 13
  • 26
  • Lemme see if I got this right: The actual Mime-type is dot-snippet, but you have used the `files.associations` settings to associate snippet files with JavaScript files — now dot-snippet files have syntax highlighting support, as if they were dot-JS files. However, you have ESLint as a dependency, or as an extension for VSCode, or both? and you need ESLint because your linting what? (Trying to wrap my head around this to help with a solution, assuming one can be found). I never linted a file type that wasn't MJS, CJS, JS or TS before. – JΛYDΞV Jul 17 '21 at 04:17
  • Thanks. I have eslint as the vsCode extension which I use for linting (mostly) `.js` files. Here, however, I am trying to get eslint to completely ignore files in the nominated folder - I don't want it to lint those files at all. Hence attempting to do that via using .eslintignore. The file association to `javascript` is simply to get syntax highlighting. – Murrah Jul 17 '21 at 23:47
  • If you haven't used a glob tester go here to check that your globs are valid https://globster.xyz/. Also, is there anyway I can see your `"./.eslintrc.json"` configuration, and maybe a snapshot of the message that ESLint gives when you hover over a red squiggly line inside one of the .snippet files? – JΛYDΞV Jul 18 '21 at 03:22
  • Thanks for your help. I have updated the question with some screenshots. Thanks also for the globster.xyz llink. I had a play and incorporated the ones I tried in the updated question. – Murrah Jul 18 '21 at 04:58
  • Try configuring the following settings to false `"javascript.format.enable": false` `"typescript.format.enable": false` `"js/ts.implicitProjectConfig.checkJs": false`, Add them to the project's __Workspace's `"./.vscode/settings.json"` file__, rather than the __User's `settings.json` File__, as the __Workspace's `settings.json` file__ has priority over the __User's `settings.json` File__ – JΛYDΞV Jul 18 '21 at 05:41
  • Also make sure that if you have the property-setting __`"js/ts.implicitProjectConfig.checkJs"`__ applied to your __`tsconfig.json` File__, that it is set to false in there as well, because your __`tsconfig.json` File__ has top-priority, and will override both, the __Workspace & User, `settings.json` Files__. The same goes for the __`jsconfig.json File`__ if you implement one of those. – JΛYDΞV Jul 18 '21 at 05:48
  • The reason I am having you do this, is because your hover widget shows that the TypeScript & JavaScript Language Features are responsible for detecting the errors that you see. See the TS(1005) number in the hover widget image you posted? Each TS number is related to some sort of issue, and the number system is implemented by TS language features. Usually the code is used to tell what is causing the error in the code, but RN we can care less about which number is applied to the error, all we care about is the fact that the error shows a TS number, and not an ESLint rule, because we are not – JΛYDΞV Jul 18 '21 at 05:54
  • Concerned so much with what is causing the error, but we are concerned with what software is highlighting the code. It makes sense that it would be a TypeScript language feature, because your file has __`/* eslint-disabled */`__ at the top of it. The __ESLint Disable Comment__ works because of the ESLint parser. When the ESLint parser & interpreter, parses and interprets that bit of code — the comment /* eslint-disabled */ — The __ESLint Parser__ known not to continue creating and interpreting your AST until the parser parses a __`/* eslint-enabled */ comment. – JΛYDΞV Jul 18 '21 at 06:00
  • So if ESLint is working, the comment has to work, unless ESLint its-self has a bug in it, which you most likely couldn't do anything about. – JΛYDΞV Jul 18 '21 at 06:01
  • @JAY-DEV: Thanks so much for all your input and help with this, much appreciated. I will work through your suggestions and report back. There will be a few days delay though. Once again, many thanks. – Murrah Jul 18 '21 at 23:29
  • Okay Murrah, its no problem really. Make sure you read about __V.S. Code's__ Language Features. You can message me any time, any day, Lately, I have been on Stack Overflow several times a day, every day. – JΛYDΞV Jul 19 '21 at 02:59

0 Answers0