Webpack 및 Browserify
Webpack과 Browserify는 대상 환경(주로 브라우저, Node와 같은 다른 환경을 대상으로 할 수 있지만) 에서 사용할 코드를 처리 하는 것과 거의 동일한 작업을 수행합니다. 이러한 처리의 결과는 대상 환경에 적합한 조립된 스크립트인 하나 이상의 번들입니다.
예를 들어 모듈로 나누어진 ES6 코드를 작성했고 브라우저에서 실행할 수 있기를 원한다고 가정해 보겠습니다. 해당 모듈이 Node 모듈인 경우 Node 환경에만 존재하므로 브라우저에서 이해하지 못합니다. ES6 모듈은 IE11과 같은 이전 브라우저에서도 작동하지 않습니다. 또한 브라우저가 아직 구현하지 않은 실험적 언어 기능(ES 다음 제안)을 사용했을 수 있으므로 이러한 스크립트를 실행하면 오류가 발생합니다. Webpack 및 Browserify와 같은 도구는 이러한 코드를 브라우저가 실행할 수 있는 형식 으로 변환하여 이러한 문제를 해결합니다. 게다가 이러한 번들에 다양한 최적화를 적용할 수 있습니다.
그러나 Webpack과 Browserify는 여러 면에서 다릅니다. Webpack은 기본적으로 많은 도구(예: 코드 분할)를 제공하는 반면 Browserify는 플러그인을 다운로드한 후에만 이를 수행할 수 있지만 둘 다 사용하면 매우 유사한 결과가 나타납니다 . 개인 취향에 달려 있습니다(Webpack이 더 유행입니다). Btw, Webpack은 작업 실행기가 아니라 파일의 프로세서일 뿐이며(소위 로더 및 플러그인에 의해 처리됨) 작업 실행기에 의해 실행될 수 있습니다.
웹팩 개발 서버
Webpack Dev Server는 Browsersync와 유사한 솔루션을 제공합니다. 개발 서버는 작업하면서 신속하게 앱을 배포하고 개발 진행 상황을 즉시 확인할 수 있습니다. 개발 서버는 코드 변경 시 브라우저를 자동으로 새로 고치거나 변경된 코드를 전파하기도 합니다. 소위 핫 모듈 교체로 다시 로드하지 않고 브라우저로 이동할 수 있습니다.
작업 실행자와 NPM 스크립트
나는 간결하고 쉬운 작업 작성을 위해 Gulp를 사용했지만 나중에 Gulp나 Grunt가 전혀 필요하지 않다는 것을 알게 되었습니다. 내가 필요로 했던 모든 것은 NPM 스크립트를 사용하여 API를 통해 타사 도구를 실행할 수 있었습니다. Gulp, Grunt 또는 NPM 스크립트 중에서 선택하는 것은 팀의 취향과 경험에 따라 다릅니다.
Gulp 또는 Grunt의 작업은 JS에 익숙하지 않은 사람들도 쉽게 읽을 수 있지만 요구하고 배워야 하는 또 다른 도구이며 저는 개인적으로 종속성을 좁히고 일을 단순하게 만드는 것을 선호합니다. 반면에 이러한 작업을 타사 도구(예: 정리 목적으로 rimraf 를 구성하고 실행하는 노드 스크립트)를 실행하는 NPM 스크립트와 (JS) 스크립트의 조합으로 교체하는 것은 더 어려울 수 있습니다. 그러나 대부분의 경우 이 세 가지는 결과 면에서 동일합니다.
예
예제의 경우, 전체 빌드 및 배포 프로세스를 다루는 NPM 및 JS 스크립트의 멋진 조합을 보여주는 이 React 스타터 프로젝트를 살펴보는 것이 좋습니다. 해당 NPM 스크립트는 루트 폴더의 scripts package.json 에서 찾을 수 있습니다. babel-node tools/run start 와 같은 명령을 주로 접하게 됩니다. 바벨 노드는 먼저 컴파일에 ES6의 파일 A CLI 도구 (생산에는 적합하지 않음)입니다 tools/run (run.js이 위치 정보 파일 도구를 기본적으로 주자 유틸리티 -). 이 주자 인수로 함수를 취하고,이 경우, 이는 그것을 실행 start - 또 다른 유틸리티 ( start.js ) 응용 프로그램 및 개발 서버를 소스 파일 (클라이언트와 서버)를 번들 및 시작에 대한 책임 (dev에 서버가 될 것입니다 아마도 Webpack Dev Server 또는 Browsersync일 것입니다).
좀 더 정확하게 말하면, start.js 는 클라이언트 측과 서버 측 번들을 모두 생성하고, 익스프레스 서버를 시작하고, 성공적인 실행 후 브라우저 동기화를 초기화합니다. 작성 당시 모습은 다음과 같습니다(최신 코드는 반응 스타터 프로젝트 참조). .
const bs = Browsersync.create(); bs.init({ ...(DEBUG ? {} : { notify: false, ui: false }), proxy: { target: host, middleware: [wpMiddleware, ...hotMiddlewares], }, // no need to watch '*.js' here, webpack will take care of it for us, // including full page reloads if HMR won't work files: ['build/content/**/*.*'], }, resolve)
중요한 부분은 프록시할 서버 주소를 설정하는 proxy.target 이며, http://localhost:3000 일 수 있으며 Browsersync 는 생성된 자산이 제공되는 http://localhost:3001 에서 수신 대기하는 서버를 시작합니다. 자동 변경 감지 및 핫 모듈 교체 포함. 보시다시피 개별 파일이나 패턴이 있는 또 다른 구성 속성 files 이 있습니다. 브라우저 동기화는 변경 사항을 감시하고 일부 발생하면 브라우저를 다시 로드하지만 주석에서 알 수 있듯이 Webpack은 HMR로 js 소스를 자체적으로 감시하므로 거기에 협력하십시오.
이제 그런 Grunt 또는 Gulp 구성에 대한 동등한 예가 없지만 Gulp를 사용하면(그리고 Grunt와 다소 유사하게) gulpfile.js에 다음과 같은 개별 작업을 작성할 수 있습니다.
gulp.task('bundle', function() { // bundling source files with some gulp plugins like gulp-webpack maybe }); gulp.task('start', function() { // starting server and stuff });
여기서는 기본적으로 스타터 키트에서와 거의 동일한 작업을 수행합니다. 이번에는 작업 실행기를 사용하여 몇 가지 문제를 해결하지만 사용법을 배우는 동안 자체 문제와 몇 가지 어려움을 나타냅니다. 의존성이 많을수록 더 많은 문제가 발생할 수 있습니다. 그리고 그것이 내가 그러한 도구를 없애고 싶어하는 이유입니다.
2018년 10월 업데이트
여전히 Front-end dev에 대해 확신이 없다면 여기에서 훌륭한 리소스를 빠르게 살펴볼 수 있습니다.
https://github.com/kamranahmedse/developer-roadmap
2018년 6월 업데이트
현대 JavaScript를 배우는 것은 처음부터 거기에 없었다면 어렵습니다. 당신이 새로운 사람이라면, 더 나은 개요를 보기 위해 이 훌륭한 글을 확인하는 것을 잊지 마십시오.
https://medium.com/the-node-js-collection/modern-javascript-explained-for-dinosaurs-f695e9747b70
2017년 7월 업데이트
최근에 Grab 팀에서 2017년 프론트엔드 개발에 접근하는 방법에 대한 포괄적인 가이드를 찾았습니다. 아래에서 확인할 수 있습니다.
https://github.com/grab/front-end-guide
나는 또한 많은 도구가 있고 각각이 다른 측면에서 우리에게 도움이 되기 때문에 이것을 꽤 오랫동안 찾았습니다. Browserify, Webpack, jspm, Grunt and Gulp 같은 도구로 나뉩니다. Yeoman or Slush 에 대해서도 들을 수 있습니다. 그것은 문제가 아닙니다. 앞으로의 명확한 길을 이해하려고 하는 모든 사람에게 혼란스러울 뿐입니다.
어쨌든 뭔가 기여하고 싶습니다.
내용의 테이블
- 내용의 테이블
- 1. 패키지 관리자
- NPM
- 나무 그늘
-
Bower 와 NPM 차이점 - 실
- jspm
- 2. 모듈 로더/번들링
- 3. 태스크 러너
- 4. 비계 도구
1. 패키지 관리자
jQuery, Bootstrap 등과 같은 라이브러리인 프로젝트 종속성 설치 및 업데이트를 단순화합니다.
모든 라이브러리 웹사이트 탐색, 아카이브 다운로드 및 압축 풀기, 프로젝트에 파일 복사 - 이 모든 것이 터미널의 몇 가지 명령으로 대체됩니다.
Node JS package manager 는 소프트웨어가 의존하는 모든 라이브러리를 관리하는 데 도움이 됩니다. package.json 이라는 파일에서 요구 사항을 정의 npm install 을 실행하면... BANG, 패키지가 다운로드되어 사용할 준비가 됩니다. front-end and back-end 라이브러리 모두에 사용할 수 있습니다.
프론트 엔드 패키지 관리의 경우 개념은 NPM과 동일합니다. bower.json 이라는 파일에 저장된 다음 bower install 을 실행합니다.
Bower는 사용자에게 npm 또는 yarn 으로 마이그레이션할 것을 권장합니다. 조심하세요
Bower 와 NPM 차이점
Bower 와 NPM 의 가장 큰 차이점은 NPM은 중첩 종속성 트리를 수행하는 반면 Bower는 아래와 같이 플랫 종속성 트리가 필요하다는 것입니다.
Bower와 npm의 차이점 은 무엇입니까?
NPM
project root [node_modules] // default directory for dependencies -> dependency A -> dependency B [node_modules] -> dependency A -> dependency C [node_modules] -> dependency B [node_modules] -> dependency A -> dependency D
나무 그늘
project root [bower_components] // default directory for dependencies -> dependency A -> dependency B // needs A -> dependency C // needs B and D -> dependency D
npm 3 Duplication and Deduplication 에 대한 업데이트가 있습니다. 자세한 내용은 문서를 참조하세요.
NPM 비해 몇 가지 장점이 더 많은 최근 Facebook 게시 JavaScript 용 패키지 관리자입니다. 그리고 Yarn을 사용하면 NPM 과 Bower 레지스트리를 모두 사용하여 패키지를 가져올 수 있습니다. 이전에 패키지를 설치한 경우, yarn offline package installs 를 용이하게 하는 캐시된 복사본을 만듭니다.
ES6 모듈 로더 위에 구축된 SystemJS 범용 모듈 로더용 패키지 관리자입니다. 자체 규칙 세트가 있는 완전히 새로운 패키지 관리자가 아니라 기존 패키지 소스 위에서 작동합니다. npm GitHub 및 npm과 함께 작동합니다. 대부분의 Bower 기반 패키지는 GitHub jspm 을 사용하여 해당 패키지를 설치할 수도 있습니다. 더 쉬운 설치를 위해 일반적으로 사용되는 대부분의 프런트 엔드 패키지를 나열하는 레지스트리가 있습니다.
Bower 와 jspm 의 차이점 보기: 패키지 관리자: Bower 대 jspm
2. 모듈 로더/번들링
규모에 관계없이 대부분의 프로젝트에는 여러 파일 간에 코드가 분할되어 있습니다. <script> 태그와 함께 각 파일을 포함할 수 <script> 는 새로운 HTTP 연결을 설정하고 모듈화의 목표인 작은 파일의 경우 연결을 설정하는 시간이 전송보다 훨씬 더 오래 걸릴 수 있습니다. 자료. 스크립트가 다운로드되는 동안 페이지의 내용을 변경할 수 없습니다.
- 다운로드 시간 문제는 간단한 모듈 그룹을 단일 파일로 연결하고 축소하면 대부분 해결할 수 있습니다.
예
<head> <title>Wagon</title> <script src=“build/wagon-bundle.js”></script> </head>
- 그러나 성능은 유연성을 희생합니다. 모듈에 상호 종속성이 있는 경우 이러한 유연성 부족은 쇼스토퍼가 될 수 있습니다.
예
<head> <title>Skateboard</title> <script src=“connectors/axle.js”></script> <script src=“frames/board.js”></script> <!-- skateboard-wheel and ball-bearing both depend on abstract-rolling-thing --> <script src=“rolling-things/abstract-rolling-thing.js”></script> <script src=“rolling-things/wheels/skateboard-wheel.js”></script> <!-- but if skateboard-wheel also depends on ball-bearing --> <!-- then having this script tag here could cause a problem --> <script src=“rolling-things/ball-bearing.js”></script> <!-- connect wheels to axle and axle to frame --> <script src=“vehicles/skateboard/our-sk8bd-init.js”></script> </head>
컴퓨터는 당신이 할 수 있는 것보다 더 잘 할 수 있고, 그렇기 때문에 도구를 사용하여 모든 것을 자동으로 단일 파일로 묶어야 하는 이유입니다.
RequireJS , Browserify , Webpack 및 SystemJS 대해 들었습니다.
JavaScript 파일 및 모듈 로더입니다. Node 와 같은 다른 JavaScript 환경에서도 사용할 수 있습니다.
예: myModule.js
// package/lib is a dependency we require define(["package/lib"], function (lib) { // behavior for our module function foo() { lib.log("hello world!"); } // export (expose) foo to other modules as foobar return { foobar: foo, }; });
main.js 에서 myModule.js 를 종속성으로 가져와 사용할 수 있습니다.
require(["package/myModule"], function(myModule) { myModule.foobar(); });
그런 다음 HTML RequireJS 와 함께 사용하는 것을 참조할 수 있습니다.
<script src=“app/require.js” data-main=“main.js” ></script>
쉽게 이해하려면 CommonJS 및 AMD 에 대해 자세히 읽어보십시오. CommonJS, AMD 및 RequireJS 간의 관계는 무엇입니까?
CommonJS 형식의 모듈을 사용할 수 있도록 설정합니다. 결과적으로 Browserify 만큼 모듈 로더가 아닙니다. Browserify 는 완전히 빌드 타임 도구이며 클라이언트 측에서 로드할 수 있는 코드 번들을 생성합니다.
node & npm이 설치된 빌드 머신으로 시작하고 패키지를 가져옵니다.
npm install -g –save-dev browserify
CommonJS 형식으로 모듈 작성
//entry-point.js var foo = require("../foo.js"); console.log(foo(4));
그리고 만족스러우면 번들 명령을 실행합니다.
browserify entry-point.js -o bundle-name.js
Browserify는 진입점의 모든 종속성을 재귀적으로 찾아 단일 파일로 조합합니다.
<script src="”bundle-name.js”"></script>
JavaScript , 이미지, CSS 등을 포함한 모든 정적 자산을 단일 파일로 묶습니다. 또한 다양한 유형의 로더를 통해 파일을 처리할 수 있습니다. CommonJS 또는 AMD 모듈 구문으로 JavaScript 를 작성할 수 있습니다. 근본적으로 더 통합되고 독단적인 방식으로 빌드 문제를 공격합니다. Browserify 에서는 Gulp/Grunt 와 긴 변형 목록 및 플러그인을 사용하여 작업을 완료합니다. Webpack Grunt 나 Gulp 가 전혀 필요하지 않은 충분한 성능을 즉시 제공합니다.
기본 사용법은 단순하지 않습니다. Browserify와 같은 Webpack 설치:
npm install -g –save-dev webpack
그리고 명령 진입점과 출력 파일을 전달합니다.
webpack ./entry-point.js bundle-name.js
현재 널리 사용 CommonJS, UMD, AMD, ES6 ) 중 하나로 런타임에 모듈을 가져올 수 있는 모듈 로더입니다. ES6 모듈 로더 폴리필 위에 구축되었으며 사용 중인 형식을 감지하고 적절하게 처리할 만큼 충분히 똑똑합니다. SystemJS 는 또한 플러그인을 사용하여 ES6 코드( Babel 또는 Traceur TypeScript 및 CoffeeScript 와 같은 다른 언어를 변환할 수 있습니다.
node module 이 무엇이며 브라우저 내에서 잘 적용되지 않는 이유를 알고 싶습니다.
더 유용한 기사:
왜 jspm 과 SystemJS 인가?
ES6 모듈화의 주요 목표 중 하나는 Github , npm 등) 어디에서나 Javascript 라이브러리를 설치하고 사용하는 것을 정말 간단하게 만드는 것입니다. 두 가지만 필요합니다.
- 라이브러리를 설치하는 단일 명령
- 라이브러리를 가져와 사용하는 코드 한 줄
그래서 jspm 으로 할 수 있습니다.
- 다음 명령을 사용하여 라이브러리를 설치하십시오.
jspm install jquery - HTML 파일 내부에서 외부 참조가 필요 없이 한 줄의 코드로 라이브러리를 가져옵니다.
display.js
var $ = require('jquery'); $('body').append("I've imported jQuery!");
그런 다음 모듈을 가져오기 전에 System.config({ ... }) 내에서 이러한 항목을 구성합니다. 일반적으로 jspm init config.js 라는 파일이 있을 것입니다.
이러한 스크립트를 실행하려면 HTML 페이지에 system.js 및 config.js SystemJS 모듈 로더를 사용하여 display.js 파일을 로드합니다.
index.html
<script src="jspm_packages/system.js"></script> <script src="config.js"></script> <script> System.import("scripts/display.js"); </script>
참고: Angular 2에서 적용한 Webpack 과 함께 npm 을 사용할 수도 있습니다. jspm SystemJS 와 통합하도록 개발되었으며 npm 소스 위에서 작동하므로 답은 사용자에게 달려 있습니다.
3. 태스크 러너
작업 실행기 및 빌드 도구는 주로 명령줄 도구입니다. 우리가 그것들을 사용해야 하는 이유: 한 마디로: 자동화 . 축소, 컴파일, 단위 테스트, 린트 와 같은 반복적인 작업을 수행할 때 수행해야 하는 작업이 줄어듭니다.
개발 환경에 대한 자동화를 생성하여 코드를 전처리하거나 구성 파일로 빌드 스크립트를 생성할 수 있으며 복잡한 작업을 처리하는 것은 매우 어려울 것 같습니다. 지난 몇 년 동안 인기가 있습니다.
Grunt 모든 작업은 완전히 독립적이고 순차적인 방식으로 차례로 실행되는 다양한 플러그인 구성의 배열입니다.
grunt.initConfig({ clean: { src: ['build/app.js', 'build/vendor.js'] }, copy: { files: [{ src: 'build/app.js', dest: 'build/dist/app.js' }] } concat: { 'build/app.js': ['build/vendors.js', 'build/app.js'] } // ... other task configurations ... }); grunt.registerTask('build', ['clean', 'bower', 'browserify', 'concat', 'copy']);
자동화는 Grunt 같지만 구성 대신 노드 응용 프로그램처럼 스트림을 사용하여 JavaScript 요즘 선호합니다.
이것은 Gulp 샘플 작업 선언입니다.
//import the necessary gulp plugins var gulp = require("gulp"); var sass = require("gulp-sass"); var minifyCss = require("gulp-minify-css"); var rename = require("gulp-rename"); //declare the task gulp.task("sass", function (done) { gulp .src("./scss/ionic.app.scss") .pipe(sass()) .pipe(gulp.dest("./www/css/")) .pipe( minifyCss({ keepSpecialComments: 0, }) ) .pipe(rename({ extname: ".min.css" })) .pipe(gulp.dest("./www/css/")) .on("end", done); });
더 보기: https://preslav.me/2015/01/06/gulp-vs-grunt-why-one-why-the-other/
4. 비계 도구
슬러시와 여만
그들과 함께 스타터 프로젝트를 만들 수 있습니다. 예를 들어, HTML 및 SCSS로 프로토타입을 구축한 다음 scss, css, img, fonts와 같은 일부 폴더를 수동으로 만드는 대신에 만들 계획입니다. yeoman 설치하고 간단한 스크립트를 실행할 수 있습니다. 그런 다음 여기에 모든 것이 있습니다.
여기에서 더 많은 것을 찾으십시오.
npm install -g yo npm install --global generator-h5bp yo h5bp
더 보기: https://www.quora.com/What-are-the-differences-between-NPM-Bower-Grunt-Gulp-Webpack-Browserify-Slush-Yeoman-and-Express
제 답변이 질문의 내용과 일치하지 않지만 구글에서 이 지식을 검색할 때 항상 질문이 맨 위에 표시되어 요약해서 답변하기로 했습니다. 도움이 되셨기를 바랍니다.
이 게시물이 마음에 들면 내 블로그( trungk18.com) 에서 더 많은 내용을 읽을 수 있습니다. 방문해 주셔서 감사합니다 :)
좋아요, 그들은 모두 약간의 유사점을 가지고 있습니다. 그들은 서로 다른 유사한 방식으로 당신을 위해 같은 일을 합니다. 저는 그것들을 아래와 같이 3개의 주요 그룹으로 나눕니다.
1) 모듈 번들러 webpack 및 browserify는 인기 있는 것으로, 작업 실행기처럼 작동하지만 더 유연하게 설정으로 모든 것을 함께 묶을 수 있으므로 예를 들어 CSS 및 Javascript를 포함하는 하나의 단일 파일에서 결과를 bundle.js로 지정할 수 있습니다. 각각에 대한 자세한 내용은 아래 세부 정보를 참조하십시오.
웹팩
webpack은 최신 JavaScript 애플리케이션을 위한 모듈 번들러입니다. 웹팩이 애플리케이션을 처리할 때 애플리케이션이 필요로 하는 모든 모듈을 포함하는 종속성 그래프를 재귀적으로 빌드한 다음 이러한 모든 모듈을 브라우저에서 로드할 소수의 번들(종종 단 하나)로 패키징합니다.
매우 구성 가능하지만 시작하려면 입력, 출력, 로더 및 플러그인의 네 가지 핵심 개념만 이해하면 됩니다.
이 문서는 이러한 개념에 대한 높은 수준의 개요를 제공하는 동시에 상세한 개념별 사용 사례에 대한 링크를 제공하기 위한 것입니다.
여기 더
브라우저화하다
Browserify는 브라우저에서 사용하기 위해 컴파일하는 node.js 스타일 모듈을 작성할 수 있게 해주는 개발 도구입니다. 노드와 마찬가지로 모듈을 별도의 파일에 작성하고 module.exports 및 export 변수를 사용하여 외부 메서드와 속성을 내보냅니다. require 함수를 사용하여 다른 모듈을 요구할 수도 있으며 상대 경로를 생략하면 node_modules 디렉토리의 모듈로 해석됩니다.
여기 더
2) 태스크 러너
gulp와 grunt는 기본적으로 그들이 하는 일, 작업을 생성하고 원할 때마다 실행하는 작업 실행자입니다. 예를 들어 CSS를 축소하기 위해 플러그인을 설치한 다음 각각에 대한 자세한 내용을 수행하기 위해 매번 실행합니다.
꿀꺽
gulp.js는 프랙탈 이노베이션(Fractal Innovations)과 GitHub의 오픈 소스 커뮤니티에서 프론트 엔드 웹 개발에서 스트리밍 빌드 시스템으로 사용하는 오픈 소스 JavaScript 툴킷입니다. Node.js 및 npm(Node Package Manager)을 기반으로 구축된 태스크 러너로 웹 개발과 관련된 축소, 연결, 캐시 버스팅, 단위 테스트, 린팅, 최적화 등과 같은 시간 소모적이고 반복적인 작업의 자동화에 사용됩니다. gulp 사용 코드 오버 구성 접근 방식은 작업을 정의하고 작은 단일 목적 플러그인에 의존하여 작업을 수행합니다. gulp 생태계에는 선택할 수 있는 1000개 이상의 플러그인이 있습니다.
여기 더
꿀꿀 거리는 소리
Grunt는 축소, 컴파일, 단위 테스트, 린팅 등과 같이 자주 사용되는 작업을 자동으로 수행하는 데 사용되는 도구인 JavaScript 작업 실행기입니다. 명령줄 인터페이스를 사용하여 파일(Gruntfile이라고 함)에 정의된 사용자 지정 작업을 실행합니다. . Grunt는 Ben Alman이 만들었으며 Node.js로 작성되었습니다. npm을 통해 배포됩니다. 현재 Grunt 생태계에는 5,000개 이상의 플러그인이 있습니다.
여기 더
3) 패키지 관리자
패키지 관리자가 하는 일은 애플리케이션에 필요한 플러그인을 관리하고 package.json을 사용하여 github 등을 통해 설치하는 것입니다. 모듈을 업데이트하고 설치하고 앱을 공유하는 데 매우 편리하며 각각에 대한 자세한 내용은 다음과 같습니다.
npm
npm은 JavaScript 프로그래밍 언어용 패키지 관리자입니다. JavaScript 런타임 환경 Node.js의 기본 패키지 관리자입니다. 이는 npm이라고도 하는 명령줄 클라이언트와 npm 레지스트리라고 하는 공개 패키지의 온라인 데이터베이스로 구성됩니다. 레지스트리는 클라이언트를 통해 액세스되며 사용 가능한 패키지는 npm 웹 사이트를 통해 찾아보고 검색할 수 있습니다.
여기 더
나무 그늘
Bower는 HTML, CSS, JavaScript, 글꼴 또는 이미지 파일을 포함하는 구성 요소를 관리할 수 있습니다. Bower는 코드를 연결하거나 축소하거나 다른 작업을 수행하지 않습니다. 필요한 패키지와 해당 종속성의 올바른 버전을 설치하기만 하면 됩니다. 시작하기 위해 Bower는 모든 곳에서 패키지를 가져와 설치하고 찾고 있는 항목을 찾고, 찾고, 다운로드하고, 저장합니다. Bower는 매니페스트 파일인 bower.json에서 이러한 패키지를 추적합니다.
여기 더
그리고 놓쳐서는 안 될 최신 패키지 매니저, 기존에 주로 사용하던 npm에 비해 실제 작업 환경에서 젊고 빠르며, 모듈 재설치 시 node_modules 폴더를 이중 확인하여 모듈 존재 여부를 확인하고, 또한 모듈을 설치하는 데 시간이 덜 걸리는 것 같습니다.
실
Yarn은 코드의 패키지 관리자입니다. 이를 통해 전 세계의 다른 개발자와 코드를 사용하고 공유할 수 있습니다. Yarn은 이 작업을 빠르고 안전하며 안정적으로 수행하므로 걱정할 필요가 없습니다.
Yarn을 사용하면 다른 문제에 대해 다른 개발자의 솔루션을 사용할 수 있으므로 소프트웨어를 더 쉽게 개발할 수 있습니다. 문제가 있는 경우 문제를 보고하거나 다시 기여할 수 있으며 문제가 해결되면 Yarn을 사용하여 모든 것을 최신 상태로 유지할 수 있습니다.
코드는 패키지(모듈이라고도 함)라는 것을 통해 공유됩니다. 패키지에는 공유되는 모든 코드와 패키지를 설명하는 package.json 파일이 포함됩니다.
여기 더
webpack 및 webpack-dev-server는 무엇입니까? 공식 문서에는 모듈 번들러라고 나와 있지만 저에게는 그저 태스크 러너일 뿐입니다. 차이점이 뭐야?
webpack-dev-server 는 Webpack 개발자가 수행하는 작업에 대한 즉각적인 피드백을 얻기 위해 사용하는 라이브 다시 로드 웹 서버입니다. 개발 중에만 사용해야 합니다.
이 프로젝트는 nof5 단위 테스트 도구에서 크게 영감을 받았습니다.
이름에서 알 수 있듯이 Webpack 은 웹용 단일 패키지 를 생성합니다. 패키지는 최소화되고 단일 파일로 결합됩니다(우리는 여전히 HTTP 1.1 시대에 살고 있습니다). Webpack 은 리소스(JavaScript, CSS, 이미지)를 결합하고 다음과 같이 주입하는 마법을 수행합니다. <script src="assets/bundle.js"></script> .
모듈 종속성과 종속성을 파악하고 함께 묶는 방법을 이해해야 하기 때문에 모듈 번들러 라고도 할 수 있습니다.
브라우저화를 어디에 사용하시겠습니까? 노드/ES6 가져오기로 동일한 작업을 수행할 수 없습니까?
Webpack 을 사용하는 것과 똑같은 작업에 Browserify 를 사용할 수 있습니다. – Webpack 이 더 컴팩트합니다.
Webpack2 의 ES6 모듈 로더 기능 은 단일 브라우저가 기본적으로 지원하지 않는 System.import 를 사용하고 있습니다.
언제 npm + 플러그인보다 gulp/grunt를 사용하시겠습니까?
Gulp, Grunt, Brokoli, Brunch 및 Bower 는 잊을 수 있습니다. 대신 npm 명령줄 스크립트를 직접 사용하고 Gulp에 대해 다음과 같은 추가 패키지를 제거할 수 있습니다.
var gulp = require('gulp'), minifyCSS = require('gulp-minify-css'), sass = require('gulp-sass'), browserify = require('gulp-browserify'), uglify = require('gulp-uglify'), rename = require('gulp-rename'), jshint = require('gulp-jshint'), jshintStyle = require('jshint-stylish'), replace = require('gulp-replace'), notify = require('gulp-notify'),
프로젝트에 대한 구성 파일을 생성할 때 Gulp 및 Grunt 구성 파일 생성기를 사용할 수 있습니다. 이렇게 하면 Yeoman 또는 유사한 도구를 설치할 필요가 없습니다.
Webpack 은 번들러입니다. Browserfy 와 마찬가지로 require 또는 import )에 대한 코드베이스를 찾고 재귀적으로 해결합니다. 또한 JavaScript와 같은 모듈뿐만 아니라 CSS, 이미지, HTML, 말 그대로 모든 것을 해결 Webpack 을 구성할 수 있습니다. Webpack 에 대해 특히 흥분되는 점은 컴파일된 모듈과 동적으로 로드된 모듈을 동일한 앱에서 결합할 수 있다는 것입니다. 따라서 특히 HTTP/1.x를 통해 실제 성능 향상을 얻을 수 있습니다. 정확히 당신이 그것을하는 방법 http://dsheiko.com/weblog/state-of-javascript-modules-2017/ 여기에서 예제로 설명했습니다. 번들러의 대안으로 Rollup.js( https: Rollup.js org/ ), 컴파일하는 동안 코드를 최적화하지만 발견된 사용되지 않는 모든 청크를 제거합니다.
AMD 의 경우 RequireJS 대신 기본 ES2016 module system 을 사용할 수 있지만 System.js ( https://github.com/systemjs/systemjs )가 로드됩니다.
npm grunt 나 gulp 와 같은 자동화 도구로 자주 사용된다는 점을 지적하고 싶습니다. https://docs.npmjs.com/misc/scripts 를 확인하세요. 저는 개인적으로 지금은 다른 자동화 도구만 피하면서 npm 스크립트를 사용합니다. 과거에는 grunt 에 매우 빠져 있었습니다. 다른 도구를 사용하면 패키지를 위한 수많은 플러그인에 의존해야 하며, 이는 종종 잘 작성되지 않고 적극적으로 유지 관리되지 않습니다. npm 은 패키지를 알고 있으므로 로컬에 설치된 패키지를 다음과 같은 이름으로 호출합니다.
{ "scripts": { "start": "npm http-server" }, "devDependencies": { "http-server": "^0.10.0" } }
실제로 패키지가 CLI를 지원하는 경우 일반적으로 플러그인이 필요하지 않습니다.
출처 : http:www.stackoverflow.com/questions/35062852/npm-vs-bower-vs-browserify-vs-gulp-vs-grunt-vs-webpack