webpack发布策略

在开发阶段, 一般会有两套方案:

  • 一套是开发期间的项目, 包含测试文件, 测试数据, 开发工具, 测试工具等相关配置, 有利于项目的开发和测试, 但是这些文件仅用于开发, 发布项目时候需要删除;
  • 另一套是部署期间的项目, 剔除那些客户用不到的测试数据, 测试工具和文件, 比较纯净, 减少了项目发布的体积, 有利于安装和部署 ;

为了满足我们的发布策略, 需要新建一个配置文件, 命名为 webpack.publish.config.jswebpack.config.js 的配置拷贝过去, 剔除一些开发配置即可 ;

devServer {
  hot: true,
  open: true,
  port: 8080
}
plugins 节点下的热更新插件删除 ;
new webpack.HotModuleReplacementPlugin()
修改 url-loader , 将图片放入统一的 images 文件夹下 ;
{ test: /\.(png|jpeg)$/, use: 'url-loader?limit=1024&name=images/[name].[ext]' }

或者使用 img- 前缀加上 7位的hash名称 ;

{ test: /\.(png|jpeg)$/, use: 'url-loader?limit=1024&name=images/img-[hash:7].[ext]' }
每次打包自动生成 dist 目录 删除老的 dist 目录
npm install clean-webpack-plugin -D
const cleanWebpackPlugin = require('clean-webpack-plugin');
plugins: [
  // 需要删除的目录
  new cleanWebpackPlugin(['dist'])
]
抽离第三方包

思路: bundle.js 只存放自己的代码 第三方包的代码全部抽离到一个另外的 js 中

const webpack = require('webpack');
const path = require('path');
module.exports = {
  entry: {
    app: path.join(__dirname, 'src/main.js'),
    // 要抽离的包
    vendors: ['jquery']
  },
  output: {
    path: path.join(__dirname, 'dist'),
    // 如果前面加了目录就代表是打包到某个文件夹 '/js/vendors.js'
    filename: '/js/bundle.js'
  },
  plugins: [
    // 实例化构造函数
    new webpack.optimize.CommonsChunkPlugin({
      // 指定要抽离的入口名称, 此处和 entry 处对应
      name: 'vendors',
      // 将来在发布的时候, jquery 就放到了 vendors.js
      // 如果前面加了目录就代表是打包到某个文件夹 '/js/vendors.js'
      filename: 'vendors.js'
    })
  ]
};
压缩 JS 代码
const webpack = require('webpack');
plugins: [
  new webpack.optimize.UglifyJsPlugin({
    compress: { // 配置压缩选项
      warnings: false,  // 移除警告
    }
  }),
  new webpack.optimize.DedupPlugin({ // 定义生产环境, 进一步压缩代码
    'process.env.NODE_ENV': '"production"'
  })
]
压缩 HTML 代码
const htmlWebpackPlugin = require('html-webpack-plugin');
const path = require('path');
plugins: [
  template: path.join(__dirname, 'src/index.html'),
  filename: 'index.html',
  minify: {
    collapseWhitespace: true, // 合并多余空格
    removeComments: true, // 移除注释
    removeAttributeQuotes: true, // 移除属性上的双引号
  }
]
抽离文件夹
npm install extract-text-webpack-plugin -D
cont ExtractTextPlugin = require('extract-text-webpack-plugin');
module.exports = {
  module: {
    {
      test: /\.css$/,
      use: ExtractTextPlugin.extract({
        fallback: 'style-loader',
        use: 'css-loader',
        // 打包到指定文件夹后可能会找不到背景图片
        // 指定抽取的时候, 自动为我们的路径加上 ../ 前缀
        publicPath: '../'
      })
    }
  },
  plugins: [
    // 抽取 css 文件并且命名为 style.css
    // 如果前面加了目录就代表是打包到某个文件夹 '/css/style.css'
    new ExtractTextPlugin('style.css')
  ]
}

参考链接: https://webpack.docschina.org/plugins/extract-text-webpack-plugin/#-extract

压缩 CSS 文件
npm install optimize-css-assets-webpack-plugin -D
var OptimizeCssAssetsPlugin = require('optimize-css-assets-webpack-plugin');
plugins: [
  // 压缩 CSS 文件
  new OptimizeCssAssetsPlugin()
]

原文地址:https://www.cnblogs.com/article-record/p/12181610.html

时间: 2024-11-09 10:43:58

webpack发布策略的相关文章

webpack-高级-发布策略

webpack的发布策略 在实际开发中,一般会有两套项目方案: 一套是开发期间的项目,包含了测试文件.测试数据.开发工具.测试工具等相关配置,有利于项目的开发和测试,但是这些文件仅用于开发,发布项目时候需要剔除: 另一套是部署期间的项目,剔除了那些客户用不到的测试数据测试工具和文件,比较纯净,减少了项目发布后的体积,有利于安装和部署! 为了满足我们的发布策略,需要新建一个配置文件,命名为webpack.publish.config.js,将webpack.config.js的配置拷贝过去,剔除一

Kubernetes资源扩容、项目发布策略

Master扩容 100台node,2台master足够了 这个在集群中讲过,可以参考之前的 Node扩容 这个在集群中讲过,可以参考之前的 Pod 扩容 以下是手动扩容为5个kubectl scale --replicas=5 deployment php-demo -n test 以下是手动缩容为3个kubectl scale --replicas=3 deployment php-demo -n test 自动扩容还得在研究 项目发布策略 蓝绿发布现在我们公司用的就是蓝绿发布策略A组 预发

用webpack发布一个vue插件包

创建库 本来以为很简单,结果配置了webpack之后,运行build就报错了,似乎不认识es6语法,于是先后安装了几个包: @babel/core @babel/preset-env babel-loader @babel/plugin-proposal-class-properties 进行了一些配置: // babel const presets = [ [ '@babel/env', { targets: '> 0.25%, not dead', useBuiltIns: 'usage',

关于代码管理和发布策略

在平时的开发过程中,版本的安排和发布对于一个完整的开发团队来说是比较重要的部分,这关系到版本能否按时递交和测试的质量的控制. 下面来说下本人在工作过程中版本的安排: 1,代码流和对应的环境 一般项目应该有至少4条流是比较正常的. a, 本地测试环境(Main Test Env)---trunk b,客户测试环境(UAT Env)---UAT流 c,生产环境(Production Env)------Prod流 d,特殊需求开(SP Env)-----CR流 2,代码流直接的关系 3,详细的mer

Citrix XenApp/XenDesktop产品发布策略调整

在2016年的Citrix Summit大会上,Citrix对其核心产品XenApp/XenDesktop产品更新及发布周期提供了更为灵活而务实的发布规则,其将会对On Premise版本的XenApp/XenDesktop产品分成下面两种新的发布模式: 1. Long TermService Release,简称LTSR版本, 2. Current Release,简称CR版本. LTSR版本的主要特点为: 1. 每1~2年选定一个较为稳定的版本标定为LTSR版本,从此版本发布之日起将可以提供

线上版本灰度发布策略

从接触运维开始,最苦逼的事情就是业务上线,为什么这么说? 就是因为有了很多的大坑队友.不是因为开发的童鞋漏提代码,就是因为测试童鞋线下测试的不到位导致代码扔到线上后出现各种问题,各种404.近期和各位童鞋研究了应对这种现象的解决方案,得到了如下结果: 上线分为如下几种等级:测试发布.预发布.灰度发布.正式发布,下面分来来针对这四种发布介绍下区别. 测试发布:写完程序在线下测试,测试的过程和结果成为测试发布. 预发布:程序经历过测试发布后要把代码在线上部署一套(和生产环境一模一样的环境),使用生产

BGP 的路由发布策略

BGP Speaker只把自己使用的路由通告给对等体.(BGP Speaker只选最优的路径给自己使用,即只将最优路由发布给对等体:) BGP Speaker从EBGP获得的路由会向自己的所有的BGP对等体通告(包括EBGP对等体和IBGP对等体). BGP Speaker从IBGP对等体获得的路由不向它的IBGP对等体通告. BGP Speaker从IBGP获得的路由是否通告给它的EBGP对等体要依IGP和BGP同步的情况来决定. 从IBGP获得的路由仅发布给它的EBGP对等体: 关闭BGP同

webpack 学习

我的 webpack.config.js module.exports = { entry: [ './src/js/app.js', './src/js/my.js' ], output: { path: __dirname + '/output/', publicPath: "/output/", filename: 'main.js' }, module: { loaders: [ {test: /\.(jpg|png)$/, loader: "url?limit=81

webpack 学习笔记

一个简单的例子,明白了是怎么操作,文件怎么制作的.在我看来和gulp/grunt区别不算太大,但很多人都说比较好,先进多了 WebPack 官网地址:  http://webpack.github.io/ 安装: #npm install -g webpack 或       #npm install webpack -g 如果是linux/mac 可以用 #sudo npm install -g webpack 创建工程 (1)创建目录并进入目录 #mkdir webpack_test &&am