J'ai vu qu'il est possible de définir une tâche dans le VSCode. Mais je ne sais pas comment définir plusieurs tâches dans le tasks.json
fichier.
Juste au cas où cela aiderait quelqu'un ... Si vous ne possédez pas/ne voulez pas gulp/grunt/etc ... ou un script shell supplémentaire pour exécuter vos commandes de tâches par proxy, "npm run" existe déjà.
c'est pour webpack et moka comme dans "Build and Test", Shift+Ctrl+B, Shift+Ctrl+T
.vscode/tasks.json:
{
"name": "npmTask",
//...
"suppressTaskName": true,
"command": "npm",
"isShellCommand": true,
"args": [
"run"
],
"tasks": [
{
//Build Task
"taskName": "webpack",
//Run On Shift+Ctrl+B
"isBuildCommand": true,
//Don't run when Shift+Ctrl+T
"isTestCommand": false,
// Show the output window if error any
"showOutput": "silent",
//Npm Task Name
"args": [
"webpack"
],
// use 2 regex:
// 1st the file, then the problem
"problemMatcher": {
"owner": "webpack",
"severity": "error",
"fileLocation": "relative",
"pattern": [
{
"regexp": "ERROR in (.*)",
"file": 1
},
{
"regexp": "\\((\\d+),(\\d+)\\):(.*)",
"line": 1,
"column": 2,
"message": 3
}
]
}
},
{
//Test Task
"taskName": "mocha",
// Don't run on Shift+Ctrl+B
"isBuildCommand": false,
// Run on Shift+Ctrl+T
"isTestCommand": true,
"showOutput": "always",
"args": [
"mocha"
]
}
]
}
package.json:
{
...
"scripts": {
"webpack": "webpack",
"mocha": "/usr/bin/mocha"
},
...
}
Ce qui m'a aidé à mieux comprendre cela, c'est la séquence d'arguments transmise à la commande. Cela peut sembler évident pour certains, mais ce n’est pas clair dans la documentation.
Omettre certains champs pour se concentrer uniquement sur la commande en cours d'envoi:
{ "command": "myCommand"
"args": ["myCommandArguments"],
"tasks" : [
{ "taskName": "myTask",
"args": ["myTaskArguments"],
"suppressTaskName": false,
}
]
}
La définition ci-dessus entraînera la commande suivante:
myCommand myCommandArguments myTaskArguments myTask
Le nom de la tâche myTask
est toujours le dernier. Depuis la version 0.4, il peut être omis avec "suppressTaskName": true
.
Essaye ça
{
"version": "0.1.0",
"command": "cmd",
"isShellCommand": true,
"args": ["/C"],
"tasks": [
{
"taskName": "install",
"args": ["npm install"]
},
{
"taskName": "build",
"args": ["gulp build"],
"isBuildCommand": true,
"problemMatcher": "$gulp-tsc"
}
]
}
J'utilise le fichier tasks.json suivant pour exécuter plusieurs scénarios de génération TypeScript. Je mets un fichier tsconfig.json dans chaque dossier, ce qui me permet d’ajuster la sortie de chaque dossier individuellement. Assurez-vous simplement de supprimer le nom de la tâche, car elle essaie de la mettre dans la chaîne de commande.
{
"version": "0.1.0",
"command": "tsc",
"showOutput": "always",
"isShellCommand": true,
"args": [],
"windows": {
"command": "tsc",
"showOutput": "always",
"isShellCommand": true
},
"tasks": [
{
"taskName": "Build the examples",
"suppressTaskName": true,
"isBuildCommand": false,
"args": ["-p", "./source/examples", "--outDir", "./script/examples"],
"problemMatcher": "$tsc"
},
{
"taskName": "Build the solution",
"suppressTaskName": true,
"isBuildCommand": false,
"args": ["-p", "./source/solution", "--outDir", "./script/solution"],
"problemMatcher": "$tsc"
}
]
}
Voici à quoi ressemble la structure de dossiers, où/script est la racine de sortie et/source est la racine d’entrée. Les deux dossiers font référence à des déclarations de type dans les dossiers/typingd et/typings. TypeScript est quelque peu limité à l’utilisation de chemins relatifs dans les références externes. Il est donc simple de simplifier les choses si ces structures de dossiers sont similaires.
Oh oui, il est plus facile de les lancer de manière sélective si vous les marquez comme étant non-construits et remplacez la clé de construction pour sélectionner une tâche spécifique dans une liste, comme ça.
// Place your key bindings in this file to overwrite the defaults
[
{ "key": "ctrl+shift+b", "command": "workbench.action.tasks.runTask" }
]
Mise à jour : Vous pouvez toujours rester complètement fictif, si vous le souhaitez. Il y a peut-être de meilleures façons de gérer les arguments, mais cela fonctionne pour moi sous OSX pour le moment.
{
"version": "0.1.0",
"isShellCommand": true,
"linux": { "command": "sh", "args": ["-c"] },
"osx": { "command": "sh", "args": ["-c"] },
"windows": { "command": "powershell", "args": ["-Command"] },
"tasks": [
{
"taskName": "build-models",
"args": ["gulp build-models"],
"suppressTaskName": true,
"isBuildCommand": false,
"isTestCommand": false
},
{
"taskName": "run tests",
"args": ["mocha ${workspaceRoot}/test"],
"suppressTaskName": true,
"isBuildCommand": false,
"isTestCommand": false
}
]
}
Je ne connais pas la bonne réponse à cette question (et j'aimerais également savoir), mais ma solution de rechange laide au cas où cela aiderait quelqu'un. Je suis sur Windows, j'ai fini par créer moi-même un script batch pouvant contenir simplement
"%1" "%2"
Ensuite, mon tasks.json ressemble à quelque chose comme
{
"version": "0.1.0",
"command": "c:\\...\\mytasks.bat"
"tasks" : [
{
"taskName": "myFirstTask",
"args": "c:\\...\\task1.exe", "${file}"],
},
{
"taskName": "mySecondTask",
"args": "c:\\...\\task2.exe", "${file}"],
},
]
}
Vous pouvez répertorier plusieurs tâches dans la propriété tasks. Quelque chose comme:
"tasks": [
{
"taskName": "build",
...
},
{
"taskName": "package",
...
}
]
Cette fonctionnalité a été ajoutée dans Code Visual Studio v1.9 (janvier 2017) . L'exemple et le texte proviennent de notes de version :
{
"version": "0.1.0",
"tasks": [
{
"taskName": "tsc",
"command": "tsc",
"args": ["-w"],
"isShellCommand": true,
"isBackground": true,
"problemMatcher": "$tsc-watch"
},
{
"taskName": "build",
"command": "gulp",
"args": ["build"],
"isShellCommand": true
}
]
}
Vous pouvez maintenant définir différentes commandes par tâche ( # 981 ). Cela permet d'exécuter différentes commandes pour différentes tâches sans écrire votre propre script Shell. Un fichier tasks.json
Utilisant des commandes par tâche ressemble à [ci-dessus.]
j'ai donc ajouté cette réponse pour montrer un exemple concret de ce qui avait été expliqué précédemment par @hurelu. Mon task.json:
{
"version": "0.1.0",
"command": "gulp",
"isShellCommand": true,
"args": [
"--no-color"
],
"tasks": [
{
"taskName": "--verbose",
"isBuildCommand": true,
"showOutput": "always",
"args": [
"vet"
],
"problemMatcher": [
"$jshint",
"$jshint-stylish"
]
},
{
"taskName": "vet",
"isTestCommand": true,
"showOutput": "always",
"args": [],
"problemMatcher": [
"$jshint",
"$jshint-stylish"
]
}
]
}
/// <reference path="typings/tsd.d.ts" />
var gulp = require('gulp');
var jshint = require('gulp-jshint');
var jscs = require('gulp-jscs');
var util = require('gulp-util');
var gulpprint = require('gulp-print');
var gulpif = require('gulp-if');
var args = require('yargs').argv;
gulp.task('vet', function () {
log('Analyzing source with JSHint and JSCS');
return gulp
.src
([
'./src/**/*.js',
'./*.js'
])
.pipe(gulpif(args.verbose, gulpprint()))
.pipe(jscs())
.pipe(jshint())
.pipe(jshint.reporter('jshint-stylish', { verbose: true }))
.pipe(jshint.reporter('fail'));
});
gulp.task('hello-world', function () {
console.log('This is our first Gulp task!');
});
////////////
function log(msg) {
if (typeof (msg) === 'object') {
for (var item in msg) {
if (msg.hasOwnProperty(item)) {
util.log(util.colors.blue(msg[item]));
}
}
} else {
util.log(util.colors.blue(msg));
}
}
{
"version": "0.1.0",
"command": "gulp",
"isShellCommand": true,
"args": [
"--no-color"
],
"tasks": [
{
"taskName": "vet",
"isBuildCommand": true,
"showOutput": "always",
"args": [
"--verbose"
],
"problemMatcher": [
"$jshint",
"$jshint-stylish"
]
},
{
"taskName": "vet",
"isTestCommand": true,
"showOutput": "always",
"args": [],
"problemMatcher": [
"$jshint",
"$jshint-stylish"
]
}
]
}
[10:59:29] Using gulpfile ~/Workspaces/Examples/Gulp/pluralsight-gulp/gulpfile.js
[10:59:29] Task 'default' is not in your gulpfile
[10:59:29] Please check the documentation for proper gulpfile formatting
[11:02:44] Using gulpfile ~/Workspaces/Examples/Gulp/pluralsight-gulp/gulpfile.js
[11:02:44] Starting 'vet'...
[11:02:44] Analyzing source with JSHint and JSCS
[gulp] src/server/app.js
[gulp] src/client/app/app.module.js
[gulp] src/client/test-helpers/bind-polyfill.js
[gulp] src/client/test-helpers/mock-data.js
[gulp] src/server/routes/index.js
[gulp] src/client/app/core/config.js
[gulp] src/client/app/core/constants.js
[gulp] src/client/app/core/core.module.js
[gulp] src/client/app/core/dataservice.js
[gulp] src/client/app/core/dataservice.spec.js
[gulp] src/client/app/customers/customer-detail.controller.js
[gulp] src/client/app/customers/customer-detail.controller.spec.js
[gulp] src/client/app/customers/customers.controller.js
[gulp] src/client/app/customers/customers.controller.spec.js
[gulp] src/client/app/customers/customers.module.js
[gulp] src/client/app/customers/customers.route.js
[gulp] src/client/app/customers/customers.route.spec.js
[gulp] src/client/app/dashboard/dashboard.controller.js
[gulp] src/client/app/dashboard/dashboard.controller.spec.js
[gulp] src/client/app/dashboard/dashboard.module.js
[gulp] src/client/app/dashboard/dashboard.route.js
[gulp] src/client/app/dashboard/dashboard.route.spec.js
[gulp] src/client/app/layout/ht-sidebar.directive.js
[gulp] src/client/app/layout/ht-sidebar.directive.spec.js
[gulp] src/client/app/layout/ht-top-nav.directive.js
[gulp] src/client/app/layout/layout.module.js
[gulp] src/client/app/layout/Shell.controller.js
[gulp] src/client/app/layout/Shell.controller.spec.js
[gulp] src/client/app/layout/sidebar.controller.js
[gulp] src/client/app/layout/sidebar.controller.spec.js
[gulp] src/client/app/widgets/ht-img-person.directive.js
[gulp] src/client/app/widgets/ht-widget-header.directive.js
[gulp] src/client/app/widgets/widgets.module.js
[gulp] src/client/tests/server-integration/dataservice.spec.js
[gulp] src/server/routes/utils/errorHandler.js
[gulp] src/server/routes/utils/jsonfileservice.js
[gulp] src/client/app/blocks/exception/exception-handler.provider.js
[gulp] src/client/app/blocks/exception/exception-handler.provider.spec.js
[gulp] src/client/app/blocks/exception/exception.js
[gulp] src/client/app/blocks/exception/exception.module.js
[gulp] src/client/app/blocks/logger/logger.js
[gulp] src/client/app/blocks/logger/logger.module.js
[gulp] src/client/app/blocks/router/router-helper.provider.js
[gulp] src/client/app/blocks/router/router.module.js
[gulp] gulpfile.js
[gulp] karma.conf.js
[11:02:48] Finished 'vet' after 4.37 s
À compter de la février 2017 , vous pouvez utiliser Terminal Runner et composer plusieurs tâches en configurant des tâches de dépendance. C'est un peu génial dans la mesure où cela ouvre un terminal intégré distinct pour chaque tâche, que vous devez surveiller pour voir si les choses fonctionnent et dont vous vous souvenez de fermer (ils "empilent"), et vous n'obtenez pas une notification "terminé" , mais ça fait le travail. La fonctionnalité est préliminaire mais prometteuse. Voici un exemple pour exécuter tsc et jspm pour une application Cordova.
{
// See https://go.Microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [{
"taskName": "tsc",
"command": "tsc",
"isShellCommand": true,
"args": ["-p", "."],
"showOutput": "always",
"problemMatcher": "$tsc"
}, {
"taskName": "jspm",
"command": "jspm",
"isShellCommand": true,
"args": ["bundle-sfx", "www/app/main.js", "www/dist/bundle.js", "--inline-source-maps", "--source-map-contents"],
"showOutput": "always"
},
{
"taskName": "build",
"isBuildCommand": true,
"dependsOn": ["tsc", "jspm"]
}]
}
J'ai une application Electron qui a besoin de compiler une feuille de style moins puis de construire et de lancer le programme. J'ai utilisé la solution de @ Ocean qui a fonctionné pour moi… rien d'autre n'a fonctionné.
Mon fichier tasks.json et build-tasks.bat se trouvent dans le répertoire .vscode à la racine du projet.
build-tasks.bat
@ECHO OFF
@ECHO Begin!
@ECHO Compiling Less
call lessc ./css/styles.less ./css/styles.css
@ECHO Build Electron App and Launch
call electron ./app.js
@ECHO Finished!
tasks.json
{
"version": "0.1.0",
"command": "${workspaceRoot}\\.vscode\\build-tasks.bat",
"isShellCommand": true,
"isWatching": true,
"showOutput": "always",
"args": [],
"tasks": [
{
"taskName": "build",
"isBuildCommand": true,
"isWatching": true,
"showOutput": "always"
}
]
}
Ce qui suit a fonctionné pour moi:
tasks.json:
{
"version": "0.1.0",
"command": "cmd",
"isShellCommand": true,
"args": [
"/c"
],
"tasks": [
{
"taskName": "bower",
"args" : ["gulp bower"],
"isBuildCommand": true,
"showOutput": "always"
},
{
"taskName": "unittest",
"suppressTaskName": true,
"args" : ["dnx -p ${cwd}\\test\\MyProject.UnitTests test"],
"isTestCommand": true,
"showOutput": "always"
}
]
}
MyProject.UnitTests\project.json:
"commands": {
"test": "xunit.runner.dnx"
}
Exécuter bower: Ctrl + Maj + B à partir de vscode Exécuter des tests: Ctrl + Maj + T à partir de vscode
Cela fonctionne pour moi ...
Je sais qu'il y a beaucoup de réponses différentes ici, mais mon approche était encore un peu différente, alors j'ai pensé ajouter ma valeur de 2 pence.
Je suis sur Windows et utilise un fichier de commandes externe pour exécuter mes commandes. Cela ressemble à la réponse de Jonathan ci-dessus, mais je n’envoie aucune commande, ce qui signifie que mon fichier "tasks.json" est différent.
Je pourrais changer cette approche avec le temps (par exemple, je n’ai pas encore appris à jouer avec gulp), mais cette méthode fonctionne parfaitement pour moi pour le moment.
J'utilise un guidon pour les modèles html, babel, donc je peux utiliser du code ES6 et un code linter pour détecter les erreurs. À la fin, le fichier de commandes lance un navigateur avec ma page de démarrage (index.html).
Voici mon fichier batch nommé run_tasks.bat:
@ECHO OFF
@ECHO Startz!
@ECHO Running Handlebars!
call handlebars html_templates -e html -f dist/html_templates.js
@ECHO Linting ES6 code
call eslint -c eslint.json src
@ECHO Running Babel ES6 to ES5
call babel src --out-dir dist --source-maps
@ECHO Now startzing page up in browser!
index.html
@ECHO Donezz it!
Et voici mon fichier tasks.json:
{
"version": "0.1.0",
"command": "${workspaceRoot}/run_tasks.bat",
"isShellCommand": true,
"isWatching": true,
"showOutput": "always",
"args": [],
"tasks": [
{
"taskName": "build",
"isBuildCommand": true,
"isWatching": true,
"showOutput": "always"
}
}
Ensuite, en VSCode, appuyez sur “CTRL + SHIFT + B” pour exécuter mon fichier de commandes.
Grâce à ce fil de discussion, j’ai maintenant la possibilité de construire et de tester le débogage, etc. c/dnxcore50, et de travailler dans vscode sur osx avec ceci:
{
"version": "0.1.0",
"command": "bash",
"args": [
],
"tasks": [
{
"taskName": "xbuild",
"args": [
"./src/Service.Host/Service.Host.csproj"
],
"showOutput": "always",
"problemMatcher": "$msCompile",
"isBuildCommand": true
},
{
"taskName": "dnx",
"args" : ["-p", "./test/Service.Tests.Unit", "test"],
"isTestCommand": true,
"showOutput": "always"
}
]
}
Je suis sûr que linux serait fondamentalement le même. La seule chose qui me dérange, c’est de garder les fichiers .csproj uniquement pour le débogage. Je suis impatient de trouver un moyen de déboguer avec dnx, bien que je n’aie pas cherché depuis deux semaines.