기계를 활용하는 방법: 태스크 러너를 통한 생산성 향상

작업 실행자는 대부분의 웹 및 모바일 응용 프로그램 뒤에서 조용히 수고하는 영웅(관점에 따라 악당)입니다. 작업 실행기는 파일 연결, 개발 서버 회전 및 코드 컴파일과 같은 수많은 개발 작업의 자동화를 통해 가치를 제공합니다. 이 기사에서는 Grunt, Gulp, Webpack 및 npm 스크립트를 다룹니다. 또한 시작하는 데 도움이 되도록 각각의 몇 가지 예를 제공합니다. 마지막에 이 게시물의 아이디어를 응용 프로그램에 통합하기 위한 몇 가지 쉬운 방법과 팁을 알려 드리겠습니다.

태스크 러너와 일반적으로 JavaScript의 발전이 프런트 엔드 환경을 지나치게 복잡하게 만들고 있다는 감정이 있습니다. 하루 종일 빌드 스크립트를 수정하는 것이 시간을 가장 잘 활용하는 것은 아니지만 적절하고 적당히 사용하면 작업 실행자가 몇 가지 이점을 얻을 수 있다는 데 동의합니다. 이것이 이 기사에서 가장 인기 있는 작업 실행자의 기본 사항을 빠르게 다루고 이러한 도구가 워크플로에 적합할 수 있는 방법에 대한 상상력을 발휘할 수 있는 확실한 예를 제공하는 것이 우리의 목표입니다.

SmashingMag에 대한 추가 정보:

• Oh-My-ZSH 및 Z로 명령줄 고급 사용자 되기
• PostCSS 소개
• Grunt와 함께 시작하고 실행하기
• 꿀꺽꿀꺽 빌드

명령줄에 대한 참고 사항

작업 실행기 및 빌드 도구는 주로 명령줄 도구입니다. 이 기사 전체에서 나는 명령줄 작업에 대한 상당한 수준의 경험과 능력을 가정할 것입니다. cd , ls , cp 및 mv 와 같은 일반적인 명령을 사용하는 방법을 이해했다면 다양한 예제를 살펴보는 동안 괜찮을 것입니다. 이러한 명령을 사용하는 것이 불편하다면 Smashing Magazine에서 훌륭한 소개 게시물을 볼 수 있습니다. 모든 것의 할아버지인 그런트와 함께 시작합시다.

꿀꿀 거리는 소리

Grunt는 최초의 인기 있는 JavaScript 기반 작업 실행기였습니다. 저는 2012년부터 어떤 형태로든 Grunt를 사용하고 있습니다. Grunt의 기본 아이디어는 특별한 JavaScript 파일 Gruntfile.js 를 사용하여 다양한 플러그인을 구성하여 작업을 수행한다는 것입니다. 방대한 플러그인 생태계가 있으며 매우 성숙하고 안정적인 도구입니다. Grunt에는 대부분의 플러그인(현재 약 5,500개)을 색인화하는 환상적인 웹 디렉토리가 있습니다. Grunt의 단순한 천재성은 JavaScript와 공통 구성 파일(makefile과 같은) 아이디어의 조합으로, 더 많은 개발자가 프로젝트에서 Grunt에 기여하고 사용할 수 있게 되었습니다. 이는 또한 Grunt가 나머지 프로젝트와 동일한 버전 제어 시스템에 배치될 수 있음을 의미합니다.

Grunt는 전투 테스트를 거쳤으며 안정적입니다. 이 글을 쓰는 즈음에 버전 1.0.0이 출시되었는데, 이는 Grunt 팀에게 큰 성과입니다. Grunt는 함께 작동하도록 다양한 플러그인을 크게 구성하기 때문에 매우 빠르게 얽힐 수 있습니다. 그러나 약간의 주의와 구성(작업을 논리 파일로 나누기!)만 있으면 모든 프로젝트에서 놀라운 작업을 수행할 수 있습니다.

필요한 작업을 수행하는 데 플러그인을 사용할 수 없는 드문 경우지만 Grunt는 자체 플러그인을 작성하는 방법에 대한 문서를 제공합니다. 자신의 플러그인을 만들기 위해 알아야 할 것은 JavaScript와 Grunt API 뿐입니다. 자신만의 플러그인을 만들 필요가 거의 없을 것이므로 꽤 인기 있고 유용한 플러그인으로 Grunt를 사용하는 방법을 살펴보겠습니다!

예

Grunt가 실제로 어떻게 작동하는지 봅시다. 명령줄에서 grunt 를 실행하면 디렉터리 루트에서 Gruntfile.js 를 찾는 Grunt 명령줄 프로그램이 실행됩니다. Gruntfile.js 에는 Grunt가 수행할 작업을 제어하는 ​​구성이 포함되어 있습니다. 이런 의미에서 Gruntfile.js 는 요리사(즉, Grunt, 프로그램)가 따르는 일종의 요리책으로 볼 수 있습니다. 좋은 요리책과 마찬가지로 Gruntfile.js 에는 많은 요리법(예: 작업)이 포함됩니다.

우리는 Grunticon 플러그인을 사용하여 가상의 웹 앱에 대한 아이콘을 생성함으로써 Grunt를 보조할 것입니다. Grunticon은 SVG 디렉토리를 가져와 여러 자산을 내보냅니다.

• SVG base-64 인코딩이 배경 이미지로 포함된 CSS 파일
• 배경 이미지로 인코딩된 SVG base-64의 PNG 버전이 있는 CSS 파일;
• 각 아이콘에 대한 개별 PNG 파일을 참조하는 CSS 파일.

세 개의 다른 파일은 브라우저와 모바일 장치의 다양한 기능을 나타냅니다. 최신 장치는 고해상도 SVG를 단일 요청(즉, 단일 CSS 파일)으로 수신합니다. SVG를 처리하지 않지만 base-64로 인코딩된 자산을 처리하는 브라우저는 base-64 PNG 스타일 시트를 받습니다. 마지막으로, 이 두 가지 시나리오를 처리할 수 없는 브라우저는 PNG를 참조하는 "전통적인" 스타일 시트를 얻게 됩니다. 이 모든 것이 SVG의 단일 디렉토리에서 제공됩니다!

이 작업의 구성은 다음과 같습니다.

 module.exports = function(grunt) { grunt.config("grunticon", { icons: { files: [ { expand: true, cwd: 'grunticon/source', src: ["*.svg", ".png"], dest: 'dist/grunticon' } ], options: [ { colors: { "blue": "blue" } } ] } }); grunt.loadNpmTasks('grunt-grunticon'); };

여기에서 다양한 단계를 살펴보겠습니다.

1. Grunt가 전역적으로 설치되어 있어야 합니다.
2. 프로젝트의 루트에 Gruntfile.js 파일을 만듭니다. npm i grunt grunt-grunticon --save-dev 를 통해 Grunticon과 함께 package.json 파일에 Grunt를 npm 종속성으로 설치하는 것도 가장 좋습니다.
3. SVG의 디렉터리와 대상 디렉터리(빌드된 자산이 들어갈 위치)를 만듭니다.
4. 로드할 아이콘을 결정하는 작은 스크립트를 HTML head 에 배치합니다.

다음은 Grunticon 작업을 실행하기 전의 디렉토리 모습입니다.

 |-- Gruntfile.js |-- grunticon | `-- source | `-- logo.svg `-- package.json
|-- Gruntfile.js |-- grunticon | `-- source | `-- logo.svg `-- package.json

이러한 것들이 설치되고 생성되면 위의 코드 조각을 Gruntfile.js 에 복사할 수 있습니다. 그런 다음 명령줄에서 grunt grunticon 을 실행하고 작업이 실행되는 것을 볼 수 있어야 합니다.

위의 스니펫은 몇 가지 작업을 수행합니다.

• 32번째 줄에 grunticon 이라는 새 config 개체를 Grunt에 추가합니다.
• icons 개체에서 Grunticon에 대한 다양한 옵션과 매개변수를 채웁니다.
• 마지막으로 loadNPMTasks를 통해 loadNPMTasks 플러그인을 가져옵니다.

다음은 Grunticon 이후의 디렉토리 모습입니다.

 |-- Gruntfile.js |-- dist | `-- grunticon | |-- grunticon.loader.js | |-- icons.data.png.css | |-- icons.data.svg.css | |-- icons.fallback.css | |-- png | | `-- logo.png | `-- preview.html |-- grunticon | `-- source | `-- logo.svg `-- package.json
|-- Gruntfile.js |-- dist | `-- grunticon | |-- grunticon.loader.js | |-- icons.data.png.css | |-- icons.data.svg.css | |-- icons.fallback.css | |-- png | | `-- logo.png | `-- preview.html |-- grunticon | `-- source | `-- logo.svg `-- package.json

자, 완료되었습니다! 몇 줄의 구성과 몇 가지 패키지 설치로 아이콘 자산 생성을 자동화했습니다! 이것이 작업 실행자의 힘인 신뢰성, 효율성 및 이식성을 설명하기 시작하기를 바랍니다.

Gulp: 빌드 시스템을 위한 LEGO 블록

Gulp는 Grunt 이후 언젠가 등장했으며 모든 구성이 아니라 실제 코드인 빌드 도구가 되기를 열망했습니다. 구성에 대한 코드 뒤에 있는 아이디어는 코드가 끝없는 구성 파일의 수정보다 훨씬 더 표현력 있고 유연하다는 것입니다. Gulp의 장애물은 Grunt보다 더 많은 기술 지식이 필요하다는 것입니다. Node.js 스트리밍 API에 익숙해야 하고 기본 JavaScript 작성에 익숙해야 합니다.

Gulp는 Node.js 스트림을 사용하기 때문에 Grunt보다 빠릅니다. 스트림을 사용한다는 것은 파일 시스템을 파일 변환을 위한 "데이터베이스"로 사용하는 대신 Gulp가 메모리 내 변환을 사용한다는 것을 의미합니다. 스트림에 대한 자세한 내용은 스트림 핸드북과 함께 Node.js 스트림 API 문서를 확인하십시오.

예

Grunt 섹션에서와 같이 간단한 예를 통해 Gulp를 단계별로 설명할 것입니다. JavaScript 모듈을 단일 앱 파일로 연결하는 것입니다.

Gulp를 실행하는 것은 Grunt를 실행하는 것과 동일합니다. gulp 명령줄 프로그램은 실행되는 디렉터리에서 요리법의 요리책(예: Gulpfile.js )을 찾습니다.

각 페이지의 요청 수를 제한하는 것은 웹 성능 모범 사례(특히 모바일에서)로 간주됩니다. 그러나 기능이 여러 파일로 분할되면 다른 개발자와 공동 작업이 훨씬 쉽습니다. 작업 실행자를 입력합니다. Gulp를 사용하여 애플리케이션에 대한 여러 JavaScript 파일을 결합할 수 있으므로 모바일 클라이언트는 여러 파일 대신 단일 파일을 로드해야 합니다.

Gulp는 Grunt와 동일한 대규모 플러그인 생태계를 가지고 있습니다. 따라서 이 작업을 쉽게 하기 위해 gulp-concat 플러그인에 의존할 것입니다. 프로젝트 구조가 다음과 같다고 가정해 보겠습니다.

 |-- dist | `-- app.js |-- gulpfile.js |-- package.json `-- src |-- bar.js `-- foo.js

두 개의 JavaScript 파일이 src 디렉토리에 있으며 dist/ 디렉토리에서 하나의 파일인 app.js 로 결합하려고 합니다. 이를 수행하기 위해 다음 Gulp 작업을 사용할 수 있습니다.

 var gulp = require('gulp'); var concat = require('gulp-concat'); gulp.task('default', function() { return gulp.src('./src/*.js') .pipe(concat('app.js')) .pipe(gulp.dest('./dist/')); });

중요한 비트는 gulp.task 콜백에 있습니다. 거기에서 gulp.src API를 사용하여 src 디렉토리에서 .js 로 끝나는 모든 파일을 가져옵니다. gulp.src API는 해당 파일의 스트림을 반환하고 pipe API를 통해 gulp-concat 플러그인에 전달할 수 있습니다. 그런 다음 플러그인은 스트림의 모든 파일을 연결하고 gulp.dest 함수에 전달합니다. gulp-dest 함수는 단순히 수신한 입력을 디스크에 씁니다.

Gulp가 스트림을 사용하여 작업에 대한 "구성 요소" 또는 "체인"을 제공하는 방법을 볼 수 있습니다. 일반적인 Gulp 워크플로는 다음과 같습니다.

1. 특정 유형의 모든 파일을 가져옵니다.
2. 해당 파일을 플러그인(concat!)에 전달하거나 일부 변환을 수행합니다.
3. 변환된 파일을 다른 블록(우리의 경우 체인을 종료하는 dest 블록)으로 전달합니다.

Grunt 예제에서와 같이 단순히 프로젝트 디렉토리의 루트에서 gulp 를 실행하면 Gulpfile.js 파일에 정의된 default 작업이 트리거됩니다. 이 작업은 파일을 연결하고 앱이나 웹사이트 개발을 계속하겠습니다.

웹팩

JavaScript 태스크 러너 클럽에 가장 최근에 추가된 것은 Webpack입니다. Webpack은 스스로를 "모듈 번들러"라고 부릅니다. 즉, CommonJS 패턴과 같은 모듈 패턴을 사용하여 여러 개별 파일에서 JavaScript 코드 번들을 동적으로 빌드할 수 있습니다. Webpack에는 로더라고 하는 플러그인도 있습니다.

Webpack은 아직 젊고 다소 조밀하고 혼란스러운 문서를 가지고 있습니다. 따라서 공식 문서를 살펴보기 전에 Pete Hunt의 Webpack 저장소를 좋은 출발점으로 추천합니다. 또한 태스크 러너가 처음이거나 JavaScript에 능숙하지 않은 경우 Webpack을 권장하지 않습니다. 이러한 문제는 제쳐두고, 여전히 Grunt 및 Gulp의 일반적인 범위보다 더 구체적인 도구입니다. 많은 사람들이 바로 이러한 이유로 Webpack을 Grunt 또는 Gulp와 함께 사용하여 Webpack이 모듈 번들링에 탁월하고 Grunt 또는 Gulp가 보다 일반적인 작업을 처리하도록 합니다.

Webpack을 사용하면 궁극적으로 브라우저용 Node.js 스타일 코드를 작성할 수 있어 생산성이 크게 향상되고 모듈을 통해 코드에서 우려 사항을 명확하게 분리할 수 있습니다. Webpack을 사용하여 Gulp 예제에서 했던 것과 동일한 결과를 얻기 위해 여러 JavaScript 파일을 하나의 앱 파일로 결합해 보겠습니다.

예

Webpack은 종종 Babel과 함께 ES6 코드를 ES5로 변환하는 데 사용됩니다. ES6에서 ES5로 코드를 변환하면 개발자가 ES6을 아직 완전히 지원하지 않는 브라우저나 환경에 ES5를 제공하면서 새로운 ES6 표준을 사용할 수 있습니다. 그러나 이 예제에서는 Gulp 예제에서 두 파일의 간단한 번들을 만드는 데 중점을 둘 것입니다. 시작하려면 Webpack을 설치하고 구성 파일 webpack.config.js 를 만들어야 합니다. 파일은 다음과 같습니다.

 module.exports = { entry: "./src/foo.js", output: { filename: "app.js", path: "./dist" } };

이 예에서는 Webpack이 src/foo.js 파일을 가리키도록 하여 종속성 그래프를 탐색하는 작업을 시작합니다. 또한 foo.js 파일을 다음과 같이 업데이트했습니다.

 //foo.js var bar = require("./bar"); var foo = function() { console.log('foo'); bar(); }; module.exports = foo;

그리고 bar.js 파일을 다음과 같이 업데이트했습니다.

 //bar.js var bar = function() { console.log('bar'); }; module.exports = bar;

이것은 매우 기본적인 CommonJS 예제입니다. 이제 이 파일이 기능을 "내보내는" 것임을 알 수 있습니다. 기본적으로 CommonJS와 Webpack을 사용하면 애플리케이션 전체에서 가져오고 내보낼 수 있는 자체 포함된 모듈로 코드를 구성할 수 있습니다. Webpack은 import 및 export 키워드를 따르고 모든 것을 하나의 파일인 dist/app.js 로 묶을 수 있을 만큼 충분히 똑똑합니다. 더 이상 연결 작업을 유지할 필요가 없으며 대신 코드의 구조를 고수하기만 하면 됩니다. 훨씬 낫다!

확장

Webpack은 "그것은 JavaScript일 뿐"이라는 점에서 Gulp와 유사합니다. 로더 시스템을 통해 다른 작업 실행자 작업을 수행하도록 확장할 수 있습니다. 예를 들어 css-loader 및 sass-loader를 사용하여 Sass를 CSS로 컴파일하고 require CommonJS 패턴을 오버로드하여 JavaScript에서 Sass를 사용할 수도 있습니다! 그러나 나는 일반적으로 Webpack을 JavaScript 모듈을 빌드하는 데만 사용하고 작업 실행을 위해 더 일반적인 다른 접근 방식을 사용하는 것을 지지합니다(예: Webpack 및 npm 스크립트 또는 Webpack 및 Gulp를 사용하여 다른 모든 것을 처리).

npm 스크립트

npm 스크립트는 최신 힙스터 열풍이며 그럴만한 이유가 있습니다. 이러한 모든 도구에서 보았듯이 프로젝트에 도입할 수 있는 종속성의 수는 결국 통제할 수 없게 될 수 있습니다. 빌드 프로세스의 진입점으로 npm 스크립트를 옹호하는 것을 본 첫 번째 게시물은 James Halliday입니다. 그의 게시물은 무시된 npm 스크립트의 힘을 완벽하게 요약합니다(강조 광산).

잘 알려지지 않은 npm run 명령이 매우 작은 구성 공간 을 유지하면서 수행해야 하는 모든 작업에 완벽하게 적합했기 때문에 JavaScript 프로젝트에서 빌드 자동화를 수행하기 위한 몇 가지 멋진 도구가 있습니다.

마지막에 마지막 비트를 잡았습니까? npm 스크립트의 주요 매력은 "매우 작은 구성 공간"이 있다는 것입니다. 이것이 npm 스크립트가 인기를 끌기 시작한 주된 이유 중 하나입니다(슬프게도 거의 4년 후). Grunt, Gulp 및 Webpack을 사용하면 결국 바이너리를 래핑하고 프로젝트의 종속성 수를 두 배로 늘리는 플러그인에 빠져들기 시작합니다.

Keith Cirkel은 npm을 사용하여 Grunt 또는 Gulp를 대체하는 방법에 대한 튜토리얼을 제공합니다. 그는 npm 스크립트의 기능을 최대한 활용하는 방법에 대한 청사진을 제공하고 필수 플러그인인 Parallel Shell(및 이와 유사한 다른 호스트)을 도입했습니다.

예

Grunt에 대한 섹션에서 인기 있는 모듈 Grunticon을 가져와서 Grunt 작업에서 SVG 아이콘(PNG 폴백 포함)을 만들었습니다. 이것은 나에게 npm 스크립트의 한 가지 문제점이었습니다. 한동안은 Grunticon을 사용하기 위해 프로젝트에 Grunt를 계속 설치했습니다. 나는 말 그대로 npm 작업에서 Grunt에게 "쉘 아웃"하여 작업 실행 시작을 달성했습니다(또는 직장에서 이것을 빌드 도구 turducken이라고 부르기 시작했을 때). 고맙게도 Grunticon 뒤에 있는 환상적인 그룹인 The Filament Group은 도구 Grunticon-Lib의 독립 실행형(Grunt-free) 버전을 출시했습니다. 이제 npm 스크립트로 아이콘을 만드는 데 사용하겠습니다!

이 예제는 일반적인 npm 스크립트 작업보다 조금 더 고급입니다. 일반적인 npm 스크립트 작업은 적절한 플래그 또는 구성 파일을 사용하여 명령줄 도구를 호출하는 것입니다. 다음은 Sass를 CSS로 컴파일하는 보다 일반적인 작업입니다.

 "sass": "node-sass src/scss/ -o dist/css",

다양한 옵션이 있는 한 줄에 어떻게 표시되는지 확인하시겠습니까? 작업 파일이 필요 없고 빌드 도구가 필요하지 않습니다. 명령줄에서 npm run sass 하기만 하면 Sass가 이제 CSS가 됩니다. npm 스크립트의 정말 좋은 기능 중 하나는 스크립트 작업을 함께 연결할 수 있다는 것입니다. 예를 들어 Sass 작업이 실행되기 전에 어떤 작업을 실행하고 싶다고 가정해 보겠습니다. 다음과 같은 새 스크립트 항목을 만듭니다.

 "presass": "echo 'before sass',

맞습니다. pre- 은 접두사를 이해합니다. 또한 post- 접두사를 이해합니다. pre- 또는 post- 접두사가 있는 다른 스크립트 항목과 이름이 같은 모든 스크립트 항목은 해당 항목 앞이나 뒤에 실행됩니다.

아이콘을 변환하려면 실제 Node.js 파일이 필요합니다. 그렇다고 너무 심각한 것은 아니다. tasks 디렉토리를 만들고 grunticon.js 또는 icons.js 라는 이름의 새 파일을 만들거나 프로젝트에서 작업하는 사람들에게 의미 있는 모든 것을 만듭니다. 파일이 생성되면 Grunticon 프로세스를 시작하는 JavaScript를 작성할 수 있습니다.

참고: 이 모든 예제는 ES6을 사용하므로 babel-node를 사용하여 작업을 실행할 것입니다. ES5와 Node.js가 더 편하다면 쉽게 사용할 수 있습니다.

 import icons from "grunticon-lib"; import globby from "globby"; let files = globby.sync('src/icons/*'); let options = { colors: { "blue": "blue" } }; let icon = new icons(files, 'dist/icons', options); icon.process();

코드로 들어가서 무슨 일이 일어나는지 알아봅시다.

1. 우리는 grunticon-lib 및 globby 두 개의 라이브러리를 import (즉, 필요). Globby는 내가 가장 좋아하는 도구 중 하나이며 파일 및 글로브 작업을 매우 쉽게 만듭니다. Globby는 Promise 지원으로 Node.js Glob( ./*.js 를 통해 모든 JavaScript 파일 선택)을 향상시킵니다. 이 경우 src/icons 디렉토리의 모든 파일을 가져오는 데 사용합니다.
2. 그렇게 하면 options 객체에 몇 가지 옵션을 설정한 다음 세 가지 인수로 Grunticon-Lib를 호출합니다.
   • 아이콘 파일,
   • 목적지,
   • options.라이브러리는 해당 아이콘을 인계받아 씹어먹고 결국 우리가 원하는 디렉토리에 SVG 및 PNG 버전을 생성합니다.
3. 거의 완료되었습니다. 이것은 별도의 파일에 있다는 것을 기억하십시오. "icons": "babel-node tasks/icons.js" 와 같이 npm 스크립트에서 이 파일을 호출하려면 "hook"을 추가해야 합니다.
4. 이제 npm run icons 를 실행할 수 있으며 아이콘은 매번 생성됩니다.

npm 스크립트는 플러그인 부채 없이 다른 작업 실행자와 비슷한 수준의 기능과 유연성을 제공합니다.

여기에서 다루는 작업 실행자의 분석

쉬운 승리

이 모든 예제와 작업 실행자가 너무 많아 보일 수 있으므로 분해해 보겠습니다. 먼저, 현재 사용 중인 태스크 러너 또는 빌드 시스템이 여기에 언급된 시스템으로 즉시 교체되어야 한다는 점을 이 기사에서 빼지 않기를 바랍니다. 이와 같은 중요한 시스템을 교체하는 것은 많은 고려 없이 수행되어서는 안 됩니다. 기존 시스템 업그레이드에 대한 조언은 다음과 같습니다. 점진적으로 수행하십시오.

래퍼 스크립트!

한 가지 점진적인 접근 방식은 기존 작업 실행자 주위에 몇 가지 "래퍼" npm 스크립트를 작성하여 사용된 실제 작업 실행자 외부에 있는 빌드 단계에 대한 공통 어휘를 제공하는 것입니다. 래퍼 스크립트는 다음과 같이 간단할 수 있습니다.

 { "scripts": { "start": "gulp" } }

많은 프로젝트에서 start 및 test npm 스크립트 블록을 활용하여 신규 개발자가 빠르게 적응할 수 있도록 돕습니다. 래퍼 스크립트는 작업 실행기 빌드 체인에 또 다른 추상화 계층을 도입하지만 npm 기본 요소(예: test )를 중심으로 표준화할 수 있는 가치가 있다고 생각합니다. npm 명령은 개별 도구보다 수명이 더 깁니다.

작은 웹팩에 뿌리기

귀하 또는 귀하의 팀이 JavaScript의 불안정한 "번들 순서"를 유지하는 데 어려움을 겪고 있거나 ES6으로 업그레이드하려는 경우 기존 작업 실행 시스템에 Webpack을 도입할 수 있는 기회를 고려하십시오. Webpack은 원하는 만큼 많이 또는 적게 사용하면서도 여전히 가치를 이끌어낼 수 있다는 점에서 훌륭합니다. 응용 프로그램 코드를 번들로 묶는 것으로 시작한 다음 babel-loader를 믹스에 추가하십시오. Webpack은 상당한 시간 동안 추가 사항이나 새로운 기능을 수용할 수 있을 정도로 깊이 있는 기능을 가지고 있습니다.

npm 스크립트로 PostCSS를 쉽게 사용

PostCSS는 작성 및 사전 처리된 CSS를 변환하고 향상시키는 훌륭한 플러그인 모음입니다. 즉, 후처리기입니다. npm 스크립트를 사용하여 PostCSS를 활용하는 것은 쉽습니다. 이전 예제와 같은 Sass 스크립트가 있다고 가정해 보겠습니다.

 "sass": "node-sass src/scss/ -o dist/css",

npm 스크립트의 lifecycle 키워드를 사용하여 Sass 작업 후에 자동으로 실행할 스크립트를 추가할 수 있습니다.

 "postsass": "postcss --use autoprefixer -c postcss.config.json dist/css/*.css -d dist/css",

이 스크립트는 Sass 스크립트가 실행될 때마다 실행됩니다. postcss-cli 패키지는 별도의 파일에 구성을 지정할 수 있기 때문에 훌륭합니다. 이 예에서는 새 작업을 수행하기 위해 다른 스크립트 항목을 추가합니다. 이것은 npm 스크립트를 사용할 때 일반적인 패턴입니다. 앱에 필요한 다양한 작업을 모두 수행하는 워크플로를 만들 수 있습니다.

결론

태스크 러너는 실제 문제를 해결할 수 있습니다. 저는 태스크 러너를 사용하여 대상이 프로덕션인지 로컬 개발인지에 따라 JavaScript 애플리케이션의 다양한 빌드를 컴파일했습니다. 또한 작업 실행기를 사용하여 Handlebars 템플릿을 컴파일하고 웹사이트를 프로덕션에 배포하고 Sass에서 누락된 공급업체 접두사를 자동으로 추가했습니다. 이것들은 사소한 작업이 아니지만 일단 태스크 러너에 래핑되면 어렵지 않게 되었습니다.

태스크 러너는 끊임없이 진화하고 변화합니다. 현재의 시대정신에서 가장 많이 사용되는 것들을 다루려고 노력했습니다. 그러나 브로콜리, 브런치, 하프와 같이 내가 언급하지 않은 다른 것들도 있습니다. 이것들은 단지 도구일 뿐임을 기억하십시오. 다른 사람들이 사용하고 있기 때문에가 아니라 특정 문제를 해결할 때만 사용하십시오. 즐거운 작업 실행 중!