In a project we our working on we use fairly strict eslint rules for good reason. Occasionally we need to break one of the rules, so we would disable a rule for a specific line. For example:
// eslint-disable-line no-console
In this case we use the eslint-disable-line syntax with the specific rule that we want disabled, to avoid accidentally disabling other rules that are important.
Occasionally a dev will sneak a file in that has // eslint-disable-line without the specific rule, or the dreaded /* eslint-disable */ at the file level.
What I am looking for is a way to force eslint to only accept directives when they include one or more specific rules, so that, for example
// eslint-disable-next-line max-len
would still disable that specific check, but
// eslint-disable-next-line
without the rule would still result in an error.
Plugin eslint-plugin-eslint-comments is what you want.
The closest I got to making eslint-disable stricter is forcing to specify which rules should be disabled using this eslint plugin
Related
I changed the drop down to “ES6 / Babel” in JSBin but it is still showing error for ES6 features. Do I need to do some additional change while enabling ES6 in JSBin?
If you hover over the yellow underlines, you’ll see a tooltip saying something like
⚠️ 'const' is available in ES6 (use esnext option) or Mozilla JS extensions (use moz).
Unfortunately, for some reason, JSBin doesn’t decide to make ESNext the default, automatically suggest making it the default, or even hint at where to find any of the mentioned options.
But fortunately, there’s Google.
There is a closed bug report with some discussion, suggesting that you can add one of the lines
// jshint esnext: true
or
/* jshint esnext: true */
at the top of your JS.
Apparently, there’s also an account setting for registered users in “Account settings” → “Preferences” → “Linting” → “jshint”, where a rule like this can be added:
{
"esnext": true
}
Unfortunately, async still won’t work, as JSHint itself complains that “'async functions' is only available in ES8 (use 'esversion: 8')”.
Note that by selecting the tab “ES6 / Babel”, you tell JSBin to transpile ES6 code down to a lower version (probably ES5.1). If your code has “errors”, i.e. uses syntax that isn’t in ES6, but a higher version, then it can’t transpile. Simply select “JavaScript” instead of “ES6 / Babel” to run JS code directly. That’ll work despite the linter showing some errors.
Here’s a few things you can try:
Try to use that esversion option in the account settings, i.e.
{
"esnext": true,
"esversion": 8
}
I didn’t get the comment variant to work, and it’s unlikely that this account option is going to work either. It seems JSBin uses an older JSHint that doesn’t support esversion.
Try to use a different Linter, e.g. ESLint, if possible, in the account settings. JSHint has had various bugs before, and is slow to adopt recent ECMAScript standards.
Use something more user-friendly and modern than JSBin.
I am writing Javascript in Visual Studio Code (not Typescript). However, I added "checkJs": true ("Enable type checking on JavaScript files") to my compilerOptions in jsconfig.json to enable automatic imports.
Now that I have done that, I'm getting Typescript errors (squiggly lines), for instance:
JSX element type 'Foo' does not have any construct or call signatures. ts(2604)
I could remove these by disabling validity checking, but then I'd lose normal Javascript validity checking.
My question is: is it possible to have automatic imports, and Javascript validity checking, but not have Typescript errors in VS Code? For instance, is there some flag I can set in jsconfig.json to disable errors with "ts" at the end?
And if not, how do I fix Typescript errors in a Javascript file ... without having to adopt Typescript?
EDIT: Just to help clarify the kind of solution I'm imagining ... let's say we were talking about ESLint here. Yes I could add a comment at the top of a file to make ESLint ignore that file, but then I lose all linting whatsoever.
I'm more looking for the equivalent of being able to say "ts2604": false or "ts*": false in an .eslintrc file, or something more like that. In other words, I don't want to adopt Typescript, or lose all type awareness either ... I just want VS Code's great Javascript features, without large chunks of my code being underlined by error/warning messages that I can't do anything about.
This could be a red herring, but are all your errors JSX related? TypeScript can handle JSX (in *.tsx ot *.jsx files) if you specify the factory to use for the JSX. The error looks like TS can't find the factory class (so it's got <Foo> and doesn't know what to pass it to). Typically this will be something like (the settings say React, but they're the same for Preact or other JSX libraries):
"compilerOptions": {
"jsx": "react",
"jsxFactory": "probably the same as transform-react-jsx setting in your plugins"
}
There's much more on that in the TS docs.
Generally I find it best practice to fix TS errors before JS anyway, but that isn't always practical, so another option is adding // #ts-ignore on the preceding line or // #ts-nocheck to skip type checking in the file.
// #ts-ignore is really intended for this kind of situation, but it's not a long term fix - you're upgrading, you know it works, you just need TS to skip the failing check for now. But, when you know the code works and TS is missing a definition somewhere it can be the right patch.
VS Code's JavaScript type checking is powered by TypeScript. The errors you are seeing in your JS files are not TypeScript language errors, they are the TypeScript engine saying: "Hey this JavaScript code looks like it is invalid". The TypeScript engine tries to understand JavaScript as well as possible, but JavaScript's dynamic nature can sometimes trip it up and you may need to help it along with some JSDoc annotations .
So ideally you should address these errors. If this is not possible, you can suppress the errors using a // #ts-ignore comment on the line above the error (this is offered as a quick fix for the error)
This TypeScript feature request also tracks the ability to suppress specific error codes.
Lately I have been coding in React with Visual Studio Code and we have a team recommandation for using ESLint extension.
It has many configuration capabilities, and the following one may match with your needs :
eslint.probe = an array for language identifiers for which the ESLint extension should be activated and should try to validate the file. If validation fails for probed languages the extension says silent. Defaults to ["javascript", "javascriptreact", "typescript", "typescriptreact", "html", "vue"].
TS compiler does not recognise jsx tags, and fails parsing them.
This only happens when I set the language to be 'typescript'
(and there is no built in language for 'typescriptReact' :(
How to configure monaco so it will accept jsx?
I tried:
monaco.languages.typescript.typescriptDefaults.setCompilerOptions(options)
I went through all of the options but none seem to work. (especially the jsx: 'react' option.
monaco.languages.typescript.typescriptDefaults.setDiagnosticsOptions({})
{ noSyntaxValidation: true})
works, but removes all validations from TS. :S
finally I made sure that the language is set to 'typescript':
monaco.editor.createModel("const a = <div></div>", "typescript", undefined)
(yes, I also tried the filepath)
tl;dr - yes, the file needs to be '.tsx'.
I had a single instance of Editor Model, with undefined filename.
The correct way to set filename is using Uri.file(filepath) as path,
and these errors are gone for .tsx (but not for .ts files).
as a bonus, I get to keep undo history, as long as I reuse existing models.
so yay!
I'm trying to apply new documentation to legacy code that is
Undocumented
Minified (We don't have the source code)
Included in the rest of the code via window.thing = thing in the minified file, instead of using modules and exports.
Used literally everywhere. It's the base framework for the entire web application.
My main intent is to get vsCode to display some intellisense for this module when I create a new page/file, rather than having to copy&paste code from other pages/files before it will tell me how to use the module's methods. And even then, it doesn't tell me how it works. Although after a few months I can now write this code somewhat reliably without looking, I've had to unravel the minified file some to find all the methods and properties available. I should be copy&pasting imports, not the whole damn file. We're also bringing in new developers soon, and (although coworkers disagree), I want to have something more for them to look at then just 'follow the pattern on the other pages'.
We are using webpack and have the ability to use modules. I prefer the module pattern, but it is clear that those who came before us did not. Using window.thing to use the module between files. My coworkers prefer to 'follow the pattern already there', rather than trying to fix old code. I don't whole-heartedly disagree, but still. So I need to make this as unobtrusive as possible.
webapp/documentation/main.js
import './thing.js';
/**#type {thing}**/
var thing; // This does not work. `thing` is marked as any.
// So I changed the type to thingModule.
/**#type {thingModule}**/
var thing; // This works.
/**#type {thingModule}*/
window.thing; // This does not work.
/**#type {thingModule}**/
var thing = window.thing; // Works for thing
// But does not change window.thing
However, none of those above propagate into the next file.
webapp/view/someFile.js
import '../../documentation/main.js';
/**#type {thingModule}**/ var thing = window.thing;
// Cannot change below this line //
thing.addView(/*blah blah blah*/);
thing.doStuff();
This allows me to look up properties of thing. But it does change the code slightly. Not much, but just enough that it would be frowned upon if left in the code when committed. Plus, if I find other modules that need similar documentation, I don't want a growing import statement for just documentation.
I need to be able to include it in a single line that only provides documentation.
import '../../documentation/main.js';
// Cannot change below this line //
thing.addView(/*blah blah blah*/);
thing.doStuff();
In this case, thing is shown as ':any' instead of ':thingModule' like it needs to be.
tl;dr:
I need to assign the #typedef to window.thing and make the jsDoc definition propagate anywhere documentation is imported. And I need to not change the actual declaration of window.thing.
When working with VS Code and Typescript or JavaScript, VS Code suggests auto imports. But when inserting the import automatically, it will add a semicolon at the end of the line. I do not want this semicolon. In addition, it is configured in my tslint as such.
Is there anyway to tell VS Code to not to insert this semicolon?
VS Code 1.38 tries to infer if semicolons should be used for auto imports and refactoring in JavaScript and TypeScript.
With VS Code 1.39 and TypeScript 3.7+, you can also explicitly set if semicolons should be used or not:
"javascript.format.semicolons": "remove",
"typescript.format.semicolons": "remove"
(Note that until VS Code 1.40 is released, you may need to install this extension in order to actually enable TypeScript 3.7 in VS Code)
There is no way of doing that at the moment, for VSCode 1.30.2, TypeScript 3.3.
You can check out the feature request here:
https://github.com/Microsoft/TypeScript/issues/19882
But this feature may come in TypeScript 3.4, as #RyanCavanaugh updated the milestone to 3.4
In the meantime, I use semi-standard style.
Also, pure standard style does not work well in VSCode as the alignment is messed up:
function foo() {
const x = {}
;['a'].map(x => console.log(x)) // <-- alignment is bad
}
In order to add to the responses:
The setting should be
"javascript.format.semicolons": "remove",
"typescript.format.semicolons": "remove"
(Not "javascrriptscript.format.semicolons")
The docs for settings say:
"javascript.format.semicolons"
can have three different options:
"ignore" -> Dont insert or remove any semicolons.
"insert" -> Insert semicolons at statement ends.
"remove" -> Remove unnecessary semicolons.
As of now there still does not seem to be an option for the mentioned problem yet, as for me when using the autocomplete functionality for log aka console.log() it did add a semicolon to the end of the line.