Widziałem, że można zdefiniować zadanie w VSCode. Ale nie jestem pewien, jak zdefiniować wiele zadań w tasks.jsonpliku.

Na wszelki wypadek, gdyby to komuś pomogło ... Jeśli nie masz / nie chcesz gulp / grunt / etc ... ani dodatkowego skryptu powłoki, który będzie wysyłał polecenia zadań, „npm run” już tam jest.

dotyczy to pakietu webpack i mokka, jak w przypadku „Buduj i testuj”, 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"
  },
  ...
}

To, co pomogło mi lepiej to zrozumieć, to sekwencja argumentów przekazywanych do polecenia. Dla niektórych może to być oczywiste, ale nie jest to jasne w dokumentacji.

Pomijanie niektórych pól, aby skupić się tylko na wysyłanym poleceniu:

{ "command": "myCommand"
  "args": ["myCommandArguments"],
  "tasks" : [ 
    { "taskName": "myTask",
      "args": ["myTaskArguments"],
      "suppressTaskName": false,
    }
  ]
}

Powyższa definicja spowoduje powstanie następującego polecenia:

myCommand myCommandArguments myTaskArguments myTask

Nazwa zadania myTaskjest zawsze ostatnia. Od wersji 0.4 można go pominąć "suppressTaskName": true.

Spróbuj tego

{
    "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"
        }
    ]
}

Używam następującego pliku tasks.json do uruchamiania wielu scenariuszy kompilacji TypeScript. Umieszczam plik tsconfig.json w każdym folderze, dzięki czemu mogę indywidualnie dostroić dane wyjściowe każdego folderu. Po prostu upewnij się, że pomijasz nazwę zadania, ponieważ próbuje umieścić ją w ciągu polecenia.

{
    "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"
        }   
    ]
}

Tak wygląda struktura folderów, gdzie / script to wyjściowy katalog główny, a / source to wejściowy katalog główny. Oba foldery odwołują się do deklaracji typów w folderze / typingd i / typings. Język TypeScript jest w pewnym stopniu ograniczony do używania ścieżek względnych w odniesieniach zewnętrznych, więc pomaga uprościć sprawę, jeśli te struktury folderów są podobne.

O tak, łatwiej jest uruchamiać je wybiórczo, jeśli oznaczysz je jako nieskompilowane i zastąpisz klucz kompilacji, aby wybrać określone zadanie z listy, na przykład ...

// Place your key bindings in this file to overwrite the defaults
[
    { "key": "ctrl+shift+b", "command": "workbench.action.tasks.runTask" }
]

Aktualizacja : Jeśli chcesz, zawsze możesz być całkowicie nieuczciwy. Mogą istnieć lepsze sposoby obsługi argumentów, ale w tej chwili działa to dla mnie pod OSX.

{
  "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
    }
  ]
}

Nie znam właściwej odpowiedzi na to pytanie (i też chciałbym wiedzieć), ale moje brzydkie obejście na wypadek, gdyby komuś pomogło. Jestem na Windowsie, skończyło się na stworzeniu prostego skryptu wsadowego, który może zawierać po prostu

"%1" "%2"

Wtedy mój plik tasks.json wygląda mniej więcej tak

{
    "version": "0.1.0",
    "command": "c:\\...\\mytasks.bat"
    "tasks" : [
        {
            "taskName": "myFirstTask",
            "args": "c:\\...\\task1.exe", "${file}"],
        },
        {
            "taskName": "mySecondTask",
            "args": "c:\\...\\task2.exe", "${file}"],
        },
    ]
}

We właściwości zadań można wyświetlić więcej niż jedno zadanie. Coś jak:

"tasks": [
    {
        "taskName": "build",
        ...
    },
    {
         "taskName": "package",
         ...
    }
]

Ta funkcja została dodana w programie Visual Studio Code v1.9 (styczeń 2017) . Przykład i tekst pochodzą z informacji o wersji :

{
  "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
    }
  ]
}

Polecenia na zadanie

Możesz teraz zdefiniować różne polecenia dla każdego zadania ( # 981 ). Pozwala to na uruchamianie różnych poleceń dla różnych zadań bez pisania własnego skryptu powłoki. tasks.jsonPlik za pomocą poleceń zadania jak wygląda [ww.]

Wydaje się, że jest to błąd VSCode od wersji 0.5.0

więc dodałem tę odpowiedź, aby pokazać działający przykład tego, co zostało wcześniej wyjaśnione przez @hurelu. Moje tasks.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"
            ]
        }
    ]
}

Mój gulp.js:

/// <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));
    }

}

Zwróć uwagę, że pierwsze zadanie używa isBuildCommand, więc uruchamia się CTRL + SHFT + B, a następne zadanie to isTestCommand, więc uruchamia się CTRL + SHFT + T. Jednak aby pierwsze zadanie zaakceptowało argumenty, nazwa zadania i argumenty musiały zostać odwrócone.

Od wersji VSCode 0.5.0 powyższe działa, ale poniższe nie działają:

{
    "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"
            ]
        }
    ]
}

Oto dane wyjściowe z task.json z poprawną kolejnością zadań i argumentów:

[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

Oto poprawne dane wyjściowe z pliku tasks.json z nazwą zadania i argumentem odwróconym podczas korzystania z argumentów:

[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

Począwszy od wydania z lutego 2017 r., Możesz używać Terminal Runner i komponować wiele zadań, konfigurując zadania zależności. To trochę dziwne, ponieważ otworzy oddzielny zintegrowany terminal dla każdego zadania, który musisz obserwować, aby sprawdzić, czy coś działa i pamiętaj o zamknięciu („układają się”), i nie otrzymasz powiadomienia „gotowe” , ale wykonuje swoją pracę. Funkcjonalność jest wstępna, ale obiecująca. Oto przykład uruchomienia tsc i jspm dla aplikacji 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"]
    }]
}

Pracowały dla mnie:

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"
  }

Uruchom bower: Ctrl + Shift + B z vscode Uruchom testy: Ctrl + Shift + T z vscode

To działa dla mnie ...

Wiem, że jest tu wiele różnych odpowiedzi, ale moje podejście znowu było trochę inne, więc pomyślałem, że dodam moje 2 pensy.

Jestem w systemie Windows i używam zewnętrznego pliku wsadowego do uruchamiania poleceń. Jest podobna do powyższej odpowiedzi Jonathana, ale nie przesyłam do niej żadnych poleceń, co oznacza, że ​​mój plik „tasks.json” jest inny.

Mogę z czasem zmienić to podejście (na przykład jeszcze nie zabrałem się za zabawę łykiem), ale ta metoda działa dla mnie w tej chwili doskonale.

Używam kierownic do tworzenia szablonów html, babel, więc mogę używać kodu ES6 i lintera kodu do wychwytywania błędów. Na koniec plik wsadowy uruchamia przeglądarkę z moją stroną startową (index.html)

Oto mój plik wsadowy o nazwie 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!

A oto mój plik 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"
        }
}

Następnie w VSCode wciskam „CTRL + SHIFT + B”, aby uruchomić plik wsadowy.

Mam aplikację Electron, która musi skompilować mniej arkuszy stylów, a następnie skompilować i uruchomić program. Użyłem rozwiązania @Oceana, które zadziałało ... nic innego nie zadziałało.

Moje pliki tasks.json i build-tasks.bat znajdują się w katalogu .vscode w katalogu głównym projektu.

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"
        }
    ]
}

Dzięki temu wątkowi mam teraz kompilację C # / dnxcore50 i testowanie debugowania itp. Pracujące w vscode na osx z tym:

{
"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"    
    }      
]
}

Jestem pewien, że linux byłby zasadniczo taki sam. Jedyną rzeczą, która mnie irytuje, jest konieczność utrzymywania plików .csproj tylko do debugowania. Z niecierpliwością czekam na sposób debugowania za pomocą dnx, chociaż nie szukałem teraz od kilku tygodni.