He visto que es posible definir una tarea en VSCode. Pero no estoy seguro de cómo definir varias tareas en el tasks.json
archivo.
He visto que es posible definir una tarea en VSCode. Pero no estoy seguro de cómo definir varias tareas en el tasks.json
archivo.
Respuestas:
Por si acaso ayuda a alguien ... Si no tiene / quiere gulp / grunt / etc ... o un script de shell adicional para enviar sus comandos de tarea, "npm run" ya está ahí.
esto es para webpack y mocha como en "Construir y probar", 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"
},
...
}
Lo que me ayudó a entender esto mejor es la secuencia de argumentos que se pasan al comando. Puede ser obvio para algunos, pero no está claro en la documentación.
Omitir algunos campos para centrarse solo en el comando que se envía:
{ "command": "myCommand"
"args": ["myCommandArguments"],
"tasks" : [
{ "taskName": "myTask",
"args": ["myTaskArguments"],
"suppressTaskName": false,
}
]
}
La definición anterior dará como resultado el siguiente comando:
myCommand myCommandArguments myTaskArguments myTask
El nombre de la tarea myTask
siempre es el último. Desde la versión 0.4 se puede omitir con "suppressTaskName": true
.
Prueba esto
{
"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"
}
]
}
Utilizo el siguiente archivo tasks.json para ejecutar múltiples escenarios de compilación de TypeScript. Pongo un archivo tsconfig.json en cada carpeta, de modo que me permite ajustar la salida de cada carpeta individualmente. Solo asegúrese de suprimir el nombre de la tarea, porque intenta ponerlo en la cadena de comando.
{
"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"
}
]
}
Así es como se ve la estructura de carpetas, donde / script es la raíz de salida y / source es la raíz de entrada. Ambas carpetas hacen referencia a declaraciones de tipo en la carpeta / typingd y en la carpeta / typings. TypeScript está algo limitado al uso de rutas relativas en referencias externas, por lo que ayuda a simplificar las cosas si estas estructuras de carpetas son similares.
Ah, sí, hace que sea más fácil iniciarlos de forma selectiva si los marca como no compilados y anula la clave de compilación para seleccionar una tarea específica de una lista, así
// Place your key bindings in this file to overwrite the defaults
[
{ "key": "ctrl+shift+b", "command": "workbench.action.tasks.runTask" }
]
Actualización : siempre puedes volverte completamente deshonesto, si quieres. Puede haber mejores formas de manejar los argumentos, pero esto me funciona bajo OSX en este momento.
{
"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
}
]
}
No sé la respuesta correcta a esto (y también me gustaría saber), pero mi fea solución en caso de que ayude a alguien. Estoy en Windows, terminé creando un simple script por lotes que podría contener simplemente
"%1" "%2"
Entonces mi tasks.json se parece a
{
"version": "0.1.0",
"command": "c:\\...\\mytasks.bat"
"tasks" : [
{
"taskName": "myFirstTask",
"args": "c:\\...\\task1.exe", "${file}"],
},
{
"taskName": "mySecondTask",
"args": "c:\\...\\task2.exe", "${file}"],
},
]
}
Puede enumerar más de una tarea en la propiedad de tareas. Algo como:
"tasks": [
{
"taskName": "build",
...
},
{
"taskName": "package",
...
}
]
tsc
y mocha
tareas.
Esta funcionalidad se agregó en Visual Studio Code v1.9 (enero de 2017) . El ejemplo y el texto provienen de las notas de la versión :
{
"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
}
]
}
Ahora puede definir diferentes comandos por tarea ( # 981 ). Esto permite ejecutar diferentes comandos para diferentes tareas sin escribir su propio script de shell. Un tasks.json
archivo que usa comandos por tarea se parece a [el anterior].
así que agregué esta respuesta para mostrar un ejemplo funcional de lo que fue explicado anteriormente por @hurelu. Mis tareas.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
A partir de la versión de febrero de 2017 , puede usar Terminal Runner y componer varias tareas configurando tareas de dependencia. Es un poco raro porque abrirá una terminal integrada separada para cada tarea, que debes observar para ver si las cosas funcionan y recordar cerrar (se "apilan"), y no recibes una notificación de "terminado" , pero hace el trabajo. La funcionalidad es preliminar pero prometedora. Este es un ejemplo para ejecutar tsc y jspm para una aplicación 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"]
}]
}
Lo siguiente funcionó para mí:
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"
}
Ejecutar bower: Ctrl + Shift + B desde vscode Ejecutar pruebas: Ctrl + Shift + T desde vscode
Esto funciona para mí ...
Sé que hay muchas respuestas diferentes aquí, pero mi enfoque fue un poco diferente nuevamente, así que pensé en agregar mis 2 centavos.
Estoy en Windows y uso un archivo por lotes externo para ejecutar mis comandos. Es similar a la respuesta de Jonathan anterior, pero no le envío ningún comando, lo que significa que mi archivo "tasks.json" es diferente.
Podría cambiar este enfoque con el tiempo (por ejemplo, todavía no he jugado con gulp) pero este método funciona perfectamente bien para mí en este momento.
Estoy usando manubrios para plantillas html, babel para poder usar el código ES6 y un linter de código para detectar errores. Al final, el archivo por lotes inicia un navegador con mi página de inicio (index.html)
Aquí está mi archivo por lotes llamado 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!
Y aquí está mi archivo 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"
}
}
Luego, en VSCode presiono “CTRL + SHIFT + B” para ejecutar mi archivo por lotes.
Tengo una aplicación de Electron que necesita compilar una hoja de estilo menos y luego compilar e iniciar el programa. Usé la solución de @ Ocean que funcionó para mí ... nada más funcionó.
Tanto mi archivo tasks.json como build-tasks.bat están en el directorio .vscode en la raíz del proyecto.
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"
}
]
}
Gracias a este hilo, ahora tengo c # / dnxcore50 build y test debug, etc. trabajando en vscode en osx con esto:
{
"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"
}
]
}
Estoy seguro de que Linux sería básicamente el mismo. Lo único que me molesta es tener que mantener los archivos .csproj solo para depurar. Espero una forma de depurar con dnx, aunque no lo he buscado en un par de semanas.