The Visual Studio Code documentation provides example tasks.json configuration that allows either typescript compilation, or markdown compilation. It does not clarify how to achieve both simultaneously.
How can that be done?
Here is a summary of the two examples...
Typescript Example
If I want VSCode to perform a typescript build step, the directions say I need to install typescript (npm install -g typescript) and then define the following task:
{
"version": "0.1.0",
"command": "tsc",
"isShellCommand": true,
"showOutput": "silent",
"args": ["*.ts"],
"problemMatcher": "$tsc"
}
Markdown Example
If I want VSCode to perform a Markdown build step, the documentation says I could install a markdown plugin of my choice (e.g. npm install -g marked), and then define a task:
{
"version": "0.1.0",
"command": "marked",
"isShellCommand": true,
"args": ["sample.md", "-o", "sample.html"]
}
Now What?
Evidently, the tasks.json may contain exactly one JSON object. Thus I cannot simply join both definitions above with a comma. On the other hand, it is possible to have multiple tasks defined within the overall task definition:
{
"version": "0.1.0",
"command": "<what goes here?>",
"isShellCommand": true,
"suppressTaskName": true, //or false?
"tasks": [
{
"taskName": "Launch Typescript"
},
{
"taskName": "Launch Markdown"
}
]
}
The above is a skeleton of legal syntax, but it is unclear how to complete the story. I am aware of discussion here and there about how to solve these kinds of issues, but there seems to be a fundamental disconnect. For example, how does VSCode know that it is supposed to execute both tasks when I press ctrl+shift+b?
Assuredly the developers of VSCode have a more direct and simpler way to accommodate multiple build tasks. Does anyone know what that is?
You are almost at the right answer.
You can define multiple build task, as shown in your last example.
What you didn't realize is that you can override global properties within the task. Meaning in one task, you can define "command" and "args" one way and in the other define it with totally different values.
In a sense, copy the meat of two examples you have above into each task in your last example
Related
If I don't want to use cargo for some reasons, I have the error: could not find 'Cargo.toml'. Is there any way to disable all Cargo.toml-related functionality?
I tried this:
{
"cargo": {
"noSysroot": true,
"sysroot": "",
"autoreload": false,
"buildScripts": { "enable": false }
}
}
But this didn't help.
To use rust-analyzer with single files, please check out https://github.com/rust-lang/rust-analyzer/pull/8955. For larger projects that don't use Cargo, you won't be able to use rust-analyzer at the moment as per this comment.
I am using typescript/node based azure functions with cosmos/sql api. Right now, I have written all my functions logic using the #azure/cosmos client. I am actively trying to refactor those functions to use input/output bindings instead; however, I am having issues finding examples of deleting entities using bindings.
Example input binding:
{
"type": "cosmosDB",
"direction": "in",
"name": "inputDocument",
"databaseName": "test",
"collectionName": "test",
"connectionStringSetting": "COSMOS_DB",
"id": "{id}",
"partitionKey": "/tenantId",
"sqlQuery": ""
}
So, to simplify things, my questions are:
Can bindings be used to perform delete operations?
Is there a way to elegantly inject an #azure/cosmos client in typescript using function bindings? I saw some examples in C#, but I could not find anything typescript related.
Any advice/suggestions would be greatly appreciated! Thank you so much :)
ESLint has global settings from all environments:
{
"env": {
"es6": true,
"es2017": true,
"es2020": true
}
}
Are the ESLint globals from all environments es6, es2017, and es2020 cumulative or incremental settings? In other words, is it enough to enable es2020 support to benefit from es6 and es2017 as well, or it is mandatory to enable each JS language version support separately?
Yes, the environments are cumulative.
This can be best seen by looking at the relevant part of the source code (linking to the current master version on GitHub).
es6 includes only the globals defined in newGlobals2015. es2017 includes newGlobals2015 and newGlobals2017, while es2020 includes newGlobals2015, newGlobals2017 and newGlobals2020.
Update
Newer versions of ESLint depend on environments defined in a separate package, which uses a different structure (it's a plain JSON file). In the end though, the global definitions haven't changed.
I've a small piece of JavaScript that I open on Visual Studio Code, I then enable #ts-check to get type hinting from TypeScript definition files.
When I refer to a type that comes from a different import VSCode will give the hint and add the following code to the beginning of the file:
import { SomeType } from 'some-module';
This is correct if I'm working on ES6 but currently I'm targetting to older runtimes and would prefer to get the generated code be written using the commonjs syntax:
var SomeType = require('some-module').SomeType;
Is there any configuration I can change to achieve this behavior?
I'm in a similar situation. I've been able to get rid of type errors but I can't seem to figure out how to get code completion to list 'require' or 'module.exports' in its options.
To get ride of type error messages.
{
"compilerOptions": {
"module": "commonjs",
"target": "es2015"
},
"exclude": ["node_modules"]
}
I have seen (don't remember where) a package.json file with custom keys starting with an underscore:
{
"name": "application-name"
, "version": "0.0.1"
, "private": true
, "dependencies": {
"express": "2.4.7"
, "jade": ">= 0.0.1"
}
, "_random": true
}
Are you allowed to do this? Is it still valid? If this is allowed, is there any documentation on the rules?
Thanks!
tl;dr:
Yes, you're allowed to add custom entries to package.json.
Choose a key name:
not already defined (details below)
not reserved for future use (details below)
avoid prefixes _ and $
and preferably use a single top-level key in which to nest your custom entries.
E.g., if you own domain example.org, you could store a custom random key as follows, inside a top-level key in reverse-domain-name notation with _ substituted for . and, if applicable, -(see comments) (e.g., org_example):
{
"name": "application-name"
, "version": "0.0.1"
, "private": true
, "dependencies": {
"express": "2.4.7"
, "jade": ">= 0.0.1"
}
, "org_example": {
"random": true
}
}
To read such custom properties, use the following technique:
require("./package.json").org_example.random // -> true
npm's package.json file format mostly complies with the CommonJS package specification:
keys that npm currently uses: https://docs.npmjs.com/files/package.json
keys defined in the spec: http://wiki.commonjs.org/wiki/Packages/1.1
As for choosing custom keys: the CommonJS package specification states (emphasis mine):
The following fields are reserved for future expansion: build, default, email, external, files, imports, maintainer, paths, platform, require, summary, test, using, downloads, uid.
Extensions to the package descriptor specification should strive to avoid collisions for future standard names by name-spacing their properties with innocuous names that do not have meanings relevant to general package management.
The following fields are reserved for package registries to use at their discretion: id, type.
All properties beginning with _ or $ are also reserved for package registries to use at their discretion.
Given the nature of JSON and this statement from the Nodejitsu documentation I don't see anything wrong with that.
NPM itself is only aware of two fields in the package.json:
{
"name" : "barebones",
"version" : "0.0.0",
}
NPM also cares about a couple of fields listed here. So as long as it is valid JSON and doesn't interfere with Node.js or NPM everything should be alright and valid.
Node's awareness of package.json files seems extends to the main field. Ref.
{ "name" : "some-library",
"main" : "./lib/some-library.js" }
If this was in a folder at ./some-library, then
require('./some-library') would attempt to load
./some-library/lib/some-library.js.
This is the extent of Node's awareness of package.json files.
To avoid possible conflicts you should prefixing your keys with some character or word. It is not recommended to use an underscore (_) or dollar sign ($) as those are reserved character prefixes, but other choices are viable.