2017-02-21 6 views
3

이 게시물의 주요 목표는 Webpack 플러그인을 작성하는 동안 오류/경고 관리에 대한 추가 정보를 얻는 것입니다.Webpack 플러그인 오류 관리

err 매개 변수를 타이밍 기반 플러그인 인터페이스 (콜백)에 전달할 수 있음을 알았지 만 Webpack 라이프 사이클, 빌드에 어떤 영향을 미치는지 더 설명하지는 않습니다 프로세스 및 사용 방법에 대해 설명합니다. 다른 유형의 플러그인 인터페이스로 오류를 관리 할 수있는 방법이 있는지는 설명하지 않습니다.

어쨌든 첫 번째 시도 같은 'emit' 라이프 사이클 단계에, 나는 err 매개 변수에 new Error('An error has occurred') 또는 단순히 'An error has occured' 값을 전달 하나에 시도했지만, 하나 경우에 따라서는 실제로에서 주어진 ERR 매개 변수를 표시

function WpAggregationPlugin() { 
    this.startTime = Date.now(); 
    this.prevTimestamps = {}; 
    } 

    WpAggregationPlugin.prototype.apply = function(compiler) { 
    compiler.plugin('emit', (compilation, callback) => { 

     var changedFiles = Object.keys(compilation.fileTimestamps).filter(watchfile => 
     this.prevTimestamps[watchfile] && 
     (this.prevTimestamps[watchfile] < (compilation.fileTimestamps[watchfile] || Infinity))) 

     // compilation.errors.push(new Error('...')) 

     this.prevTimestamps = compilation.fileTimestamps; 

     if(changedFiles.length <= 0) { 
     callback() 
     } else { 
     process.stdout.write(`File modification detected :\n${JSON.stringify(changedFiles, null, 4)}\n`) 
     callback('...') 
     } 
    }); 
    }; 

    module.exports = WpAggregationPlugin; 

는 그래서 여분의 콜백 웹팩 프로세스를 구축해야하기 위해 다음과 같은 방법을 호출 할 필요 재개 : :입니다 콘솔로 (IE는 슬프게도 오류 특정 착색없이), 및 웹팩-SEV 서버 붙어있어

... 
     if(changedFiles.length <= 0) { 
     callback() 
     } else { 
     process.stdout.write(`File modification detected :\n${JSON.stringify(changedFiles, null, 4)}\n`) 
     callback('...') 
     callback()  // EXTRA CALL 
     } 
    ... 

불행히도, 이런 식으로, 나는 어떤 식 으로든 Webpack 라이프 사이클에 영향을 미치지 않으면 서 무색의 문자열을 stdout으로 간단히 표시합니다.

내 오류의 경우 빨간색 오류 메시지를 표시하고 새로운 빌드가 결국 오류없이 실행되는 플러그인을 만들 때까지 번들 빌드 프로세스가 valid 상태로 끝나지 않도록하기 위해 노력하고 있습니다.

경고 관리에 관해서는 플러그인 자체 내에서 직접 오른쪽 색상으로 process.stdout.write()을 호출하거나 컴파일 매개 변수에서 경고 컬렉션을 제공하여 수행해야한다고 생각합니다. 그러나 비슷하게보고했습니다. 지금까지이 질문에 ... 단지 추측입니다 : p

나는이 응용 프로그램에서 주위에 흩어져있는 모든 번역을 하나의 파일에 모으는 것이 목표 인 작은 빌드 도구를 작성했기 때문에이 질문을 던집니다. 우리 고객이 수십 가지가 아닌 하나의 번역 파일을 다루도록하기 위해서입니다.

"하나의 촬영"모드 나 시계 모드로 실행할 수 있지만이 방법을 Webpack 빌드 프로세스의 플러그인으로 직접 통합하는 것이 가장 좋습니다.

Webpack을 처음 접했을 때 나는이 "건축 학적"선택에 대해 당신에게 의견을 말하면서, 나는 분명히 그 모든 잠재 성을 포용하지 않았으며 나는 아마도/그걸로 끝내야합니다 (물론이 게시물의 주된 이유가 아니므로 사이드 메모로).

미리 감사드립니다 그것에 대해 유용한 정보;)!

답변

0

현재 Webpack 플러그인을 작성 중이며 동일한 문제가 발생했습니다. 참조 용으로 기존 플러그인을 살펴 보았지만 같은 결론에 도달했습니다. 이에 대한 인프라가 없습니다. 예를 들어 추출물 - 텍스트 웹팩-플러그인을 촬영 :

https://github.com/webpack-contrib/extract-text-webpack-plugin/blob/master/index.js

을 그것은 기본적으로 console.warnthrow new Error 물건을 처리하기 위해 사용합니다. compilation 개체에 오류를 푸시 할 수는 있지만 처리 방법을 알지 못해 일부 진입 점에서는 사용할 수 없습니다.

+0

마침내 이것을 정리했습니다 : 실제적인 고려는'compilation.errors.push (새로운 오류 ('왜 빌드 실패했다 '))'그리고'callback()'을 잊지 마라. 이'errors.push'는 번들이 webpack-dev-server에 의해 처리되는 것을 막을 것이고, 명령 줄에 빨간색으로 표시 될 것입니다. 그리고 http : // yourDN : YourPort/webpac-dev-server'를 실행하면 webpack 헤더 부분의 클라이언트 쪽에서이 오류가보고됩니다. 오류를 수정하기 전에 개발자가 코딩을하기 전에 오류를 수정하도록하십시오.) – Lemmy

6

마침내 webpack 코드 디버깅 하루 반 후에 이것을 분류했습니다.

실제 거래는 웹팩 컴파일의 오류 수집이 방법으로 공급하는 것입니다

compilation.errors.push(new Error('explain why the build failed'))

그리고 물론

상관없이 callback()을 잊지 않는 당신의 플러그인이 실패하거나하지.

errors.push는 :

  • 가 웹팩 헤더에보고 된 오류 메시지를 표준 출력에 빨간색으로 표시되는 오류 메시지가 번들을 처리하기 위해 웹팩-dev에 서버를 방지 클라이언트/브라우저 측의 일부 ... 앱 대신!

최신 지점이 재개 세션을 코딩하기 전에이 오류를 수정하기 위해 DEVS을 시행 그냥 완벽하다 (당신은 물론 http://yourDN:yourPort/webpack-dev-server 통해 그것을 액세스하는 경우)) 웹팩 문서는 너무 구식이다

그냥 동정 ... 확실히 Webpack 2에 문제가되는 의사 단점이 없기를 바랍니다. :