Existing answers about disabling ESLint answer the question "How can I disable ESLint in one file, a pattern of files, or a directory of files?" Is there an easy way to just stop a project from checking ESLint at all?
My goal here is to run a Cypress test with a debugger; command and possibly many other syntax errors due to temporary commenting out. I want to be able to test partially complete code and then toggle type checking back on. Bonus points if the solution stops TypeScript checking as well.
Things I tried that didn't work:
adding /* eslint-disable */ to cypress/support/e2e.js
launching cypress open with DISABLE_ESLINT_PLUGIN=true
My app is using create-react-app.
As a workaround for this, you can disable the no-debugger rule in development but leave it on in production, as per https://stackoverflow.com/a/62592912/733092:
'no-debugger': process.env.NODE_ENV === 'production' ? 'error' : 'warn'
Another workaround is to put the per-file disable text in a PyCharm Live Template so you can auto-type
/* eslint-disable */
// #ts-nocheck
at the top of the file you're in.
Related
I have LSP and LSP-typescript packages installed.
I also have directory with typescript code snippets (read: gists), which i sometimes open with sublime. When i interact with such a snippet, i usually get some typecript syntax warnings, coming from LSP. Incorrect syntax in this case is OK of course, because snippets are examples with unmet dependencies, missing constants etc...
Is there an option to disable LSP in such directories where I do not want any checks to be performed?
Apparently it is not possible to exclude directories, but you can achieve something similar by creating new project and disabling chosen LSP-clients at project level. It is doable via command palette => LSP: Disable language server in project.
I am using go in vscode. The problem is that it seems to be linting the golang source code and is coming up with warnings. How do I disable the linting of the go source code itself.
Couple of recommendation:
Update everything (VScode, Go, VSCode-Go extension)
Make sure your workspace (or opened folder) is limited to your project sources.
Use golangci-lint as Lit Tool
Activate the "Go: Lint on save" setting, with 'package' as the selected option.
I've configured stylelint to read SCSS and I keep getting browser hack warnings on SCSS items like $variables and !default. I loaded in the stylelint-scss plugin thinking this might fix it but it hasn't. I want the browser hacks rule to be enabled for true browser hacks but I'll have to turn this off if it fails on all of the SCSS items.
Does anyone know how I can keep the browser hack rule enabled but not have it fail on non-browser hacks like the standard variables for SCSS?
The no-browser-hacks rule is not compatible with SCSS syntax. This is documented in the rule's README.
I can think of three options available to you:
Continue to use SCSS and turn off the no-browser-hacks rule.
Continue to use SCSS and contribute SCSS compatibility to stylehacks (the underlying library that powers the rule). The author of the library is happy to accept a Pull Request for this.
Discontinue using SCSS in favour of using standard CSS syntax and constructs.
Adding the stylelint-scss plugin will not resolve the issue as it provides additional rules specific to SCSS syntax and constructs. It does not change stylelint's core rules.
I am running Mocha tests (with Chai as an assertion library).
At the moment JSHint fires a warning every time it encounters a line like this one:
expect(err).to.be.null;
The reported problem is:
Expected an identifier and instead saw 'null' (a reserved word).
Is there any relax option for JSHint to fix this issue?
At the moment the only solution I have only found is to include the special option at the beginning of the file:
/*jshint -W024 */
The problem with that is that it needs to be included in every test file (and I would rather separate JSHint options from the code itself). I do not seem to have found much in the options list.
You can put the following settings:
{
"expr": true,
"es5": true
}
in a .jshintrc file at the top level of your test suite. I'm still on version 1.1.0 of jshint and thus need both settings but apparently version 2.0.0 and above has es5 set to true by default. The expr setting is documented here. There no longer a reference for es5 probably because it is default and cannot be turned off. (Jshint 2.0.0 will raise an error if you try to set it manually.)
The way jshint operates when checking a file is by looking for a .jshintrc file in the same directory as your file. If not found, then it looks one level up. If not found there, then it looks one more level up, etc.
I actually realized that I had an enforcing option enabled.
To fix it I only had to set:
"es3": false
(Since it is the default, the same can be obtained removing the option completely)
We like the Warnings as Errors setting as we have a policy of not checking in code with warnings and this is the only effective way we have found to enforce it.
We also like to use the Obsolete attribute to flag methods that should not be used any more.
Problem is that adding a Obsolete attribute to a method or class immediately causes tons of projects to not build (not to mention problems if a .NET API call is deprecated).
Does anyone have a good solution to this?
We want a visible, hard-to-ignore indicator that you are using a deprecated API but that does not cause the build to fail. We want to see the warnings in the IDE and in CI builds.
A simple solution would be to have a build configuration (e.g. your debug build configuration) without warnings as errors. If, however, the point is to flag to your developers that something is wrong on build, that's no good as they'll forget to do a release build before they check in.
Alternately, rather than using "warnings as errors" you could set up your ruleset to throw errors itself rather than raise warnings. This will mean, of course, that non-CA warnings won't cause errors.
The best solution, I think, would be to handle it on the server side. Ideally you'd have some sort of gated checkin so that your code repository rejects commits that don't build using its build definition (with warnings-as-errors on, and your developers can leave warnings-as-errors off). I suspect that's a TFS-2k10-only feature though.
This other stack overflow post should help:
https://stackoverflow.com/a/468166/9195608
Basically it says:
You can add a WarningsNotAsErrors-tag in the project file.
<PropertyGroup>
...
...
<WarningsNotAsErrors>612,618</WarningsNotAsErrors>
</PropertyGroup>
Note: 612 and 618 are both warnings about Obsolete
The difference between 612 and 618 is the comment of the ObsoleteAttribute. An ObsoleteAttribute without comment generates the error 612, and one with a comment generates 618.
As explained here /sdl (Enable Additional Security Checks), if you switch off SDL the compiler will treat it as a warning.