I use coc-eslint and coc-tsserver but find it frustrating that eslint's errors always appear before tsserver's
For instance this is a common error when I haven't imported Foo yet.
[eslint #typescript-eslint/no-unsafe-call] [E] Unsafe construction of an any
──────────────────────────────────────────────────────────────────────────────
https://typescript-eslint.io/rules/no-unsafe-call
──────────────────────────────────────────────────────────────────────────────
[tsserver 2304] [E] Cannot find name 'Foo'.
Is there a way to configure change the priority of coc plugins, or configure coc-eslint to emit all diagnostics as warnings instead of errors?
Related
I use LunarVim for editing Haskell code. Automatic type and import hints are quite annoying. How to turn them off?
For example, after the import Text.ParserCombinators.Parsec import, the following hint is automatically showed right after import statement: import Text.ParserCombinators.Parsec ( car, noneof, string , ... ). If types for a function are not specified, the hint with the inferred types is automatically showed after the first line of the function.
HLS is very helpful, but the code looks cluttered due to those hints. It would be great to disable only the hints keeping all the HLS functionality. The default LunarVim setup is used with some plugins unrelated to Haskell and some changes are made in themes.
Thanks.
On Linux, under ~/.config/lvim/lsp-settings, try creating a file haskell.json with the following setting:
{
"haskell.plugin.importLens.globalOn": "false"
}
You can do it from within Lunarvim with :LspSettings haskell
This should fix the import hints. As for the inferred types, I couldn't find a specific option.
However, you can run haskell-language-server generate-default-config to print the default configuration and check the definitions of these options in https://haskell-language-server.readthedocs.io/en/latest/configuration.html#configuring-your-editor
Note: although I have lunarvim installed, I prefer the vanilla neovim with some plugins installed, such as Coc.
I'm trying to compile a Salesforce sfdx plugin which is a node project with (among others) the following dependency chain that ultimately leads to fake-timers#^7.1.0:
#salesforce/command#2.2.0 -> #oclif/test#^1.2.4 -> fancy-test#^1.4.3 -> #types/sinon#* -> #sinonjs/fake-timers#^7.1.0.
When compiling it with the Typescript compiler tsc, I get the following error:
node_modules/#sinonjs/fake-timers/types/fake-timers-src.d.ts:11:28 - error TS2304: Cannot find name 'queueMicrotask'.
11 queueMicrotask: typeof queueMicrotask;
~~~~~~~~~~~~~~
Found 1 error.
error Command failed with exit code 1.
This looks like a bug in fake-timers-src.d.ts but introduced in 7.1.0 so I could try to lock the version at 7.0.5 but that might break all kinds of other things.
Does anybody who uses/maintains fake-timers know how to fix this? Or will this be fixed in a future version?
BTW I'm a total NodeJS n00b so if there's something really obvious here that I'm missing, please be kind and just tell me what it is :)
Thanks!
Frans
Frans! fatso83 from the Sinon team here :)
The problem here has all to do with TypeScript and nothing to do with Node, so I feel your pain. No wonder you are wondering. The problem is that the definitions are probably missing that property. For version 7 we tried to generate TypeScript definitions from JSDoc. This works reasonably well for simpler type, but ultimately, TypeScript is more powerful in describing types than JSDoc (like the typeof operator), so it was an uphill battle that would never result in the same quality as the types available from the external Definitely Typed project. We ended up abandoning that effort and therefore this will not be fixed, but it will naturally go away with version 8 (that will not be shipping its own types).
What you can do is this: npm install #sinonjs/fake-timers#6 (which is the previous version) and npm install #types/sinonjs__fake-timers#6 (which are the externally maintained types).
You might find some background for this in this issue.
If you use something like $FlowIssue it's not guaranteed to be in everyone's .flowconfig file. If you declare a library interface, that seems to only work for the given project, not in other projects that import your package (even if you provide the .flowconfig and interface files in your NPM package).
Here's the code I'm trying to suppress errors for in apps that use my package:
// $FlowIssue
const isSSRTest = process.env.NODE_ENV === 'test' // $FlowIssue
&& typeof CONFIG !== 'undefined' && CONFIG.isSSR
CONFIG is a global that exists when tests are run by Jest.
I previously had an interface declaration for CONFIG, but that wasn't honored in user applications--perhaps I'm missing a mechanism to make that work?? With this solution, at least there is a good chance that user's have the $FlowIssue suppression comment. It's still not good enough though.
What's the idiomatic solution here for packages built with Flow?
Declaring a global variable
This is the way to declare a global variable:
declare var CONFIG: any;. Instead of any you could/should use the actual type.
Error Suppression
With flow v0.33 they introduced this change:
suppress_comment now defaults to matching // $FlowFixMe if there are
no suppress_comments listed in a .flowconfig
This means that there is a greater chance of your error being suppressed if you use $FlowFixMe.
Differences in .flowconfig between your library and your consumers' code are a real issue, and there is no way to make it so that your code can be dropped into any other project and be sure it will typecheck. On top of that, even if you have identical .flowconfigs, you may be running different versions of Flow. Your code may typecheck in one version, but not in another, so it may be the case that consumers of your library will be pinned to a specific version of Flow if they want to avoid getting errors reported from your library.
Worse, if one library type checks only in one version of Flow, and another type checks only in another version, there may be no version of Flow that a consumer can choose in order to avoid errors.
The only way to solve this generally is to write library definition files and publish them to flow-typed. Unfortunately, this is currently a manual process because there is not yet any tooling that can take a project and generate library definitions for it. In the mean time, simply copying your source files to have the .js.flow extension before publishing will work in some cases, but it is not a general solution.
See also https://stackoverflow.com/a/43852211/901387
I ran into the following error which is quite surprising. I added a field to the AppSettings in a Yesod app (using the Yesod scaffholding) and to my surprise, everything compiled even though I didn't do anything else (I was expecting to have to add somewhere a default value to the construction of AppSettings, but not). I got a runtime error instead telling me that a field was missing.
It appears that the only construction to AppSetting uses the RecordWildCards extension and looks like AppSettings{..}. Not defining the new field didn't generate an error but a warning (I didn't see it, because I was running test in continuous mode using stack test --file-watch). How is that possible ?
I try to reproduce the problem in a simple file and I get an error not a warning. So why do I get a warning for Yesod ? Is it a compilation flag or something ?
Edit
This is not specific to Yesod. I've made the test again with a simple file and it generates a warning not an error.
According to changelog in GHC, "that not a bug, it's a feature": https://ghc.haskell.org/trac/ghc/ticket/5334
You can change this behavior by changing type of your fields to strict (prepend a ! to type name - like !Int) - however, then you lose laziness (more about effects of strict types: Advantages of strict fields in data types)
Of course, you can also make it an error by slamming in -Werror compilation option, but then you need to be very strict about your code (no unused imports, no unused variables, even when unpacking a record etc.), or get rid of -Wall and turn on only warnings you perceive as important.
For an Windows app, the option for the default language is found in Package.appxmanifest under the project. However, I do not know where to find the setting for a class library, because there is nothing like Package.appxmanifest under a class library project.
As a result, after I add Strings\zh-CN\Resources.resw and a few strings into a class library project, I get a few warnings, saying:
MakePRI : warning 0xdef00522: Resources found for language(s) 'zh-cn' but no resources found for default language(s): 'en-US'. Change the default language or qualify resources with the default language. http://go.microsoft.com/fwlink/?LinkId=231899
MakePRI : warning 0xdef01051: No default or neutral resource given for '...'. The application may throw an exception for certain user configurations when retrieving the resources.
No actual help from "fwlink" as usual.
Although nothing bad actually happens because the app gets zh-CN as its default language, it is still quite annoying and I would like to eliminate the warnings to turn on "treat warnings as errors".
Try to manually edit the <DefaultLanguage> in the csproj file. It's under the first <PropertyGroup> subtree.
Here is a snippet of the context where you should be able to find this tag:
<DefaultLanguage>zh-CN</DefaultLanguage>
<TargetPlatformIdentifier>UAP</TargetPlatformIdentifier>
<TargetPlatformVersion>10.0.10240.0</TargetPlatformVersion>
<TargetPlatformMinVersion>10.0.10240.0</TargetPlatformMinVersion>
<MinimumVisualStudioVersion>14</MinimumVisualStudioVersion>