I'd like to disable the warning AL1025, because of the nature of the AL compiler, I get a lot of warnings related to my node_modules folder. Apparently, it should be possible to suppress warnings in the app.json like this
"suppressWarnings": ["AL1025"]
But I still get those warnings:
Microsoft (R) AL Compiler version 7.4.7.43721
Copyright (C) Microsoft Corporation. All rights reserved
Compilation started for project 'ABC Sample Ext' containing '11' files at '19:58:7.337'.
/Users/username/Dev/abc-workspace/abc-sample/node_modules/he/LICENSE-MIT.txt(1,1): warning AL1025: The file at location '/Users/username/Dev/abc-workspace/abc-sample/node_modules/he/LICENSE-MIT.txt' does not match any definition.
What am I doing wrong?
You need to define a ruleset that tells the compiler which warnings/errors to ignore.
There are two parts to this:
Define the ruleset
Activate the ruleset
The ruleset is defined in JSON format with a name, description and collection of rules. A rule must have an id, a description and justification.
An example could be:
{
"name": "Custom ruleset",
"description": "Set some rules as hidden",
"rules": [
{
"id": "AL1025",
"action": "Info",
"justification": "Allow non-AL files in workspace"
}
]
}
Then you need to activate the rules you defined. This is done by defining al.ruleSetPath in your settings.json (in the .vscode folder):
{
"al.ruleSetPath": "./custom.ruleset.json"
}
Related
As directed by the VSCode github repo - I have an simple ask. Is it possible to set a human readable application name for a VSCode Workspace?
At the moment, my .code-workspace file looks like.
{
"folders": [
{
"name": "Some project",
"path": "../some-project"
}
]
}
Having a look through the Settings (File->Preferences->Settings) for the Workspace there is a plethora of settings. Curiously there is an appName environment variable - but surely there should be a way of customising this.
The title bar looks like the following with acme.app (Workspace):
Curiously the workspace filename is called acme.app.code-workspace.
I spotted window.title in settings when having a look earlier. You can customise it in the code-workspace. I am not sure whether this would be the best way. Would be nice if we could set an environment variable workspaceName or something and use that - if we needed to use elsewhere.
If you add the settings section - then add the window.title it will default the value to ${dirty}${activeEditorShort}${separator}${rootName}${separator}${appName}.
{
"folders": [
{
"name": "Some project",
"path": "../some-project"
}
]
"settings": {
"window.title": "${dirty}${activeEditorShort}${separator}${rootName}${separator}${appName}"
}
}
Here you can see the following:
dirty - displays an indicator of whether the current file has changed
activeEditorShort - the current file
separator - configured separator i.e. '-'
rootName - defaults to acme.app (Workspace)
appName - defaults to Visual Studio Code
So you could change the rootName to be the human-readable text:
"window.title": "${dirty}${activeEditorShort}${separator}MY SUPER PROJECT${separator}${appName}"
Which gives us:
we are using cobol now, but this config error keeps on appearing and I do not know how to fix this thing. Any help would really mean alot. (Just a beginner and trying to learn vscode)
Late, but perhaps worth it. Currently there is a cobenv.bat or .sh (if you are on linux). The whole path to the file may differ for me is this:
C:\msys64\mingw64\bin\cobenv.cmd
You'll notice that if you execute the file and run the compiler everything works fine, but once you close that bash the error shows up again.
That's because the scope of those variables was just that session. You may execute it every time you run the compiler or you can make those variables to persist on your system. In my case I did the later, modifying cobenv.cmd
But not those lines with the variable PATH.
So this lines, i.e., whenever we encounter this same three variables. For instance, after a certain if in that file we encounter:
setx "COB_LIBRARY_PATH" "%MINGW_ROOT_PATH%lib\gnucobol%COB_LIBRARY_PATH%"
setx "COB_COPY_DIR" "%MINGW_ROOT_PATH%share\gnucobol\copy"
setx "COB_CONFIG_DIR" "%MINGW_ROOT_PATH%share\gnucobol\config"
Default value: set.
New value: setx.
Delete the = to comply with the correct syntax. Check the compiler with different new session.
This message is only presented in vscode's Terminal after you've entered a command there, it is actually not related to vscode.
The "common" way with vscode would be to create a vscode task for the compilation and configure a problem matcher, too, so vscode is able to parse the messages. For details see vscode docs "Integrate with External Tools via Tasks".
As the message is coming from the GnuCOBOL compiler it may be reasonable to check in its discussion board, which also includes a note how to use your setup of vscode with GnuCOBOL MinGW package, this would be your starting point, assuming D:\COBOL is the place where you have your sources (and this is the alos the workspaceFolder as in your screenshot), D:\COBOL\copy where your copybook reside and D:\GnuCOBOL where the MinGW package is:
{
"version": "2.0.0",
"tasks": [
{
"label": "GnuCOBOL - cobc (compile single file)",
"type": "shell",
"command": "cobc",
"args": [
"-I${workspaceFolder}\\copy",
"${file}"
],
"problemMatcher": "$gnucobol3-cobc",
"options": {
"env": {
"COB_CFLAGS": "-I\"D:\\GnuCOBOL\\include\"",
"COB_CONFIG_DIR": "D:\\GnuCOBOL\\config",
"COB_COPY_DIR": "D:\\GnuCOBOL\\copy",
"COB_LDFLAGS": "-L\"D:\\GnuCOBOL\\lib\"",
"COB_LIBRARY_PATH": "D:\\GnuCOBOL\\extras",
"PATH": "D:\\GnuCOBOL\\bin:${env:PATH}"
}
},
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
Instead of directly calling cobc you could also call cobc.bat or similar, then create it with all your default options set there (or, if you use the official mingw packages, just call the set_env.cmd) then call the compiler.
Concerning "how to fix that message" - make sure you have the "config" directory of GnuCOBOL and have COB_CONFIG_DIR set to it either in the task definition or outside of vscode (for example by starting vscode from the "Developer prompt for GnuCOBOL MinGW" (which is the set_env.cmd distributed with it).
I am really sorry for this newbie question but I can't see how solve that...
I installed linter-stylelint and tried to configure it like it's said there:
https://atom.io/packages/linter-stylelint
So:
- I placed a stylelint.config.js file in my project.
- In the settings, I checked Use standard
- But can't see what I have to do to "Add a stylelint section in your package.json"
On my Mac I see the file:
/Users/eric/node_modules/stylelint-config-standard
But I don't know what code do I have to insert inside...
By the way, when I try to use linter-stylelint in a css file I get the error message:
Unable to parse stylelint configuration
Unexpected token :
In my stylelint.config.js, I have the following code for now:
{
"extends": "stylelint-config-standard"
"rules" {
"no-unsupported-browser-features": [ true, { "severity": "warning" }]
}
}
Thanks if you can help me!
;)
Paul
So: - I placed a stylelint.config.js file in my project. - In the settings, I checked Use standard
According to the docs you reference, you should either place a stylelint.config.js file or check "Use standard".
I get the error message Unable to parse stylelint configuration Unexpected token :
This is because the JSON of your configuration file is invalid. It is missing both a comma and a colon. Use a service like JSONLint to validate JSON. Your fixed config is:
{
"extends": "stylelint-config-standard",
"rules": {
"no-unsupported-browser-features": [true, {
"severity": "warning"
}]
}
}
Even though this config is valid JSON, it won't work because the no-unsupported-browser-features rule is no longer built into stylelint. It is, however, available as a plugin. You'll need to follow the plugin's instructions if you wish to use it.
I am really sorry for this newbie question
It's fine. We are all newbies in the beginning! As you're just getting started with stylelint, I suggest you remove the stylelint.config.js file and ensure the "Use Standard" box is checked. This is likely the quickest way to get going. Once you are more comfortable with the tool, you can investigate creating your own configuration file for your specific needs.
I'm trying to configure the max line length (among other settings) for TS Lint in VS code but no matter what changes I make it doesn't 'take'.
So, the first strange thing is that VS code's TS Lint error for max line length says I've exceeded the 140 character limit but in the various config files I've found it only ever mentions 120 characters as the default.
I've changed this to 200 characters, disabled / enabled the extension but still get the 140 character warning. Does anyone know where and how to configure this setting? The documentation online is clear enough but I don't appear to have a tslint.json file and within the node_modules => tslint => lib => rules folder the setting is 120 and changing it makes no difference.
Edit 2020-09-30
Microsoft deprectaded the old plugin and released a newer, completely rewritten version with additional features here.
For the new plugin the setting "tslint.enable": true does not exists and is not needed anymore.
Original Answer
You need to create a tslint.json (in your workspace root) and set something like this to disable the maximum line length:
{
"defaultSeverity": "error",
"extends": [
"tslint:recommended"
],
"jsRules": {},
"rules": {
"max-line-length": [false]
},
"rulesDirectory": []
}
Furthermore, ensure that the following options are set in the in the vscode user settings (settings.json):
"tslint.configFile": "./path/to/tslint/relative/from/workspaceroot/tslint.json",
"tslint.enable": true
The tslint.configFile option can be empty if the file is in the root directory of your workspace.
Further rules can be found here.
Can the Typescript compiler ignore the cannot find module 'x' error on import expressions such as:
//How to tell the compiler that this module does exists
import sql = require('sql');
There are multiple npm libraries such as node sql that doesn't have existing typings
Is there a way to tell the compiler to ignore this error other than creating a new definition file with the declare module x ... ?
As of TypeScript 2.6 (released on Oct 31, 2017), now there is a way to ignore all errors from a specific line using // #ts-ignore comments before the target line.
The mendtioned documentation is succinct enough, but to recap:
// #ts-ignore
const s : string = false
disables error reporting for this line.
However, this should only be used as a last resort when fixing the error or using hacks like (x as any) is much more trouble than losing all type checking for a line.
As for specifying certain errors, the current (mid-2018) state is discussed here, in Design Meeting Notes (2/16/2018) and further comments, which is basically
"no conclusion yet"
and strong opposition to introducing this fine tuning.
If you just want to bypass the compiler, you can create a .d.ts file for that module, for instance, you could create a sql.d.ts file and inside have this:
declare module "sql" {
let _sql: any;
export = _sql;
}
Solved This
By default #ts-check looks for definitions of a module, either its your own code or external libraries.
Since we are not using ES6 style modules, then we must we are using
commonjs, check my jsconfig.json file for help.
{
"compilerOptions": {
"target": "es6",
"module": "commonjs",
"lib": ["es5", "es6", "es7"]
},
"include": ["src/**/*"],
"exclude": ["node_modules"],
"typeAcquisition": { "enable": true }
}