장기간 캐싱은 어떻게 작동하나요?

Question

프로젝트에서 이것을 사용하지는 않았지만 yeoman에서 이것을 발견했습니다. webpack.make.js.

이 코드 :

config.plugins.push(new CommonsChunkPlugin({ 
    name: 'vendor', 

    // filename: "vendor.js" 
    // (Give the chunk a different name) 

    minChunks: Infinity 
    // (with more entries, this ensures that no other module 
    // goes into the vendor chunk) 
})); 



    config.output = { 
    // Absolute output directory 
    path: BUILD ? path.join(__dirname, '/dist/client/') : path.join(__dirname, '/.tmp/'), 

    // Output path from the view of the page 
    // Uses webpack-dev-server in development 
    publicPath: BUILD || DEV || E2E ? '/' : `http://localhost:${8080}/`, 
    //publicPath: BUILD ? '/' : 'http://localhost:' + env.port + '/', 

    // Filename for entry points 
    // Only adds hash in build mode 
    filename: BUILD ? '[name].[hash].js' : '[name].bundle.js', 

    // Filename for non-entry points 
    // Only adds hash in build mode 
    chunkFilename: BUILD ? '[name].[hash].js' : '[name].bundle.js' 
}; 

왜 우리가 [hash] 및 CommonsChunkPlugin 사용 놈이야? 무엇을 의미합니까?

이러한 도구로 간단한 예를 얻을 수 있습니까?

Answer 1

[hash]은 번들 파일의 체크섬으로 만들어집니다.

번들의 내용이 변경되면 변경되고 그렇지 않으면 변경되지 않습니다. 이는 브라우저 캐시 최적화에 유용합니다. 새 버전의 JS 코드를 서버에 배포하면 캐시 설정에 관계없이 브라우저가 이전 버전과 다른 이름으로 파일을 가져오고 최신 버전을 가져옵니다. see webpack documentation on long term caching

CommonsChunkPlugin →

은로드 시간을 최적화하기 위해 다른 번들로 번들을 분할하는 데 사용됩니다.

번들 -a.js가있는 페이지 A와 번들 -b.js가있는 페이지 B가 있다고 가정 해보십시오. 두 번들은 동일한 라이브러리 모듈 X를 포함와 Y는 당신의이

→ see webpack documentation on code splitting

을 Y. 번들-lib.js 페이지 A와 B에로드를 호출 라이브러리 모듈 X 등을 포함 할 별도의 청크 번들을 만들 수 있습니다

→ see webpack documentation on the plugin, with examples