用户
 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,登录网站

小程序社区 首页 资讯/观点 查看内容

用webpack4开发小程序

Rolan 2019-6-4 00:22

哈,本人是REACT系开发者,工作中需要不停的折腾webpack,为了顺带学习VUE的开发思想和思路,顺理成章的请缨为公司小程序打个框架基础。前期也去了解了下各个小程序开发框架,大体上是通过转义的思路来解决小程序和V ...

哈,本人是REACT系开发者,工作中需要不停的折腾webpack,为了顺带学习VUE的开发思想和思路,顺理成章的请缨为公司小程序打个框架基础。前期也去了解了下各个小程序开发框架,大体上是通过转义的思路来解决小程序和VUE/REACT的模板、逻辑关系,不做展开讨论了。只是从本人角度分享通过webpack来构建小程序的开发架构。

通过观察小程序的原有架构,不难发现其已经是一套比较完善的mvvm架构了(类VUE),融合了VUE及REACT的一些特点(以VUE为主),但却有一些不足,缺失了前端开发人员常用的npm包的引入,动态样式的编译等等提升开发效率的工作环境、模式。因此我想如果通过webpack4来为原有架构做一个有益的补充,这样原生架构不就很完美了吗?

思路

对等编译输出小程序项目的所有文件(严格按照小程序需要的文件及目录结构输出)。js/wxs通过babel编译输出,wxml/json直接输出,wxss通过stylus编译输出(我们使用stylus开发样式),顺带使用webpack抽离公共模块文件 common.js ,并将runtime运行时抽离作为一个独立文件。这样既精简了代码,又享用到了webpack为我们带来的好处。嗯,看上去很简单嘛,实际上却是踩了不少的坑!脚上的茧老厚了~~~

webpack module配置

module: {
  rules: [
    {
      test: /\.(wxml|axml)/, // 为支付宝小程序留了个伏笔,哈哈
      use: [
        relativeFileLoader(isWechat ? 'wxml' : 'axml'),  // 这里使用file-loader简单封装了一下
        'extract-loader',
        'html-loader'
      ]
    },
    {
      test: /\.(jp(e?)g|png|gif)$/,
      use: relativeFileLoader()
    },
    {
      test: /\.wxss$/,
      include: SRC,
      use: relativeFileLoader(),
    },
    {
      test: /\.wxs$/,
      include: SRC,
      exclude: /node_modules/,
      use: [
        relativeFileLoader(),
        {
          loader: 'babel-loader',
          options: {
            babelrc: false,
            presets: [
              'es2015', 
              'stage-0'
            ]
          },
        }
      ]
    },
    {
      test: /\.js$/,
      use: {
        loader: 'happypack/loader',
        options: {
          id: 'babel'
        }
      },
      exclude: /node_modules/,
    },
    {
      test: /\.styl$/,
      include: SRC,
      use: [
        relativeFileLoader(isWechat ? 'wxss' : 'acss'),
        'stylus-loader'
      ]
    }
  ]
},
复制代码

熟悉webpack的同学通过上面的moudle配置应该能够看出资源文件编译的思路,当然直接这样配置肯定做不到正确编译,还有一些坑需要踩

全文件entry

为了对等输出,我们需要把所有文件整理为entry给webpack处理,这样的好处是js能够使用npm包,所有文件都能够支持热更新机制(webpack的热更新响应非常快,gulp的热更新很难精细控制,当项目足够大的时候,响应很慢)

function entries(dir) {
  var jsFiles = {}
  let _partten = /[\/|\\][_](\w)+/;
  let re_common = /(.*)\/common\//
  const accessExts = ['.wxml', '.wxss', '.styl', '.wxs', '.json', '.png', '.jpg', '.jpeg', '.gif']
  if (fse.existsSync(dir)) {
    globby.sync([`${dir}/**/*`, `!${dir}/js/**/cloudfunctions`, '!node_modules', `!${dir}/dist`]).forEach(function (item) {
      if (!re_common.test(item)) {
        if (!_partten.test(item)) {
          const fileObj = path.parse(item)
          const xcxSrc = path.join(dir, 'js')
          if (~item.indexOf(xcxSrc)) {
            const fileStat = fs.statSync(item)
            const relativeFile = item.replace(xcxSrc, '')
            let relativeKey = relativeFile.replace(fileObj.ext, '').substring(1)
            if (fileObj.ext == '.js') {
              jsFiles[relativeKey] = item
            }
            else {
              if (accessExts.indexOf(fileObj.ext) > -1) {
                jsFiles['nobuild__' + relativeFile] = item
              }
            }
          }
        }
      }
    })
  }
  return jsFiles
}
复制代码

上述是entry的生成代码,涵盖了小程序目录结构下的所有需要的文件,并加上了一些特定的标识,以便于后续文件编译输出

非JS文件的输出

在entry方法中我们将wxml,wxss等文件作为entry统统灌给webpack去处理,正常我们使用webpack时是不会把非js文件作为entry输给webpack的。你猜webpack会报错吗,----- 哈哈,报错就讲不下去了,webpack会傻傻的把每个entry文件都当做js来对待,并且正常输出, *.wxml.js ,等等,这是什么鬼,我并不需要这样的东东。加个插件来处理一下

compiler.hooks.compilation.tap('wpConcatFile', (compilation, params) => {
  compilation.hooks.beforeChunkAssets.tap('wpConcatFile', () => {
    compilation.chunks = compilation.chunks.filter(function (item) {
      return item.name.indexOf('nobuild__') == -1
    })
  })
  ...
  ...
}
复制代码

nobuild__ 是在生成entry代码是给非js文件加上的prefix前缀,在插件中我们排除掉非js,将正常的js文件重新chunk,js文件就能够正常的输出了,那么那些非js文件呢?webpack并不会编译生成它们,中途它们就会被module中的 xx-loader 处理完,然后被 file-loader 给甩出去了。

全局变量替换

将全局变量替换为微信小程序的 wx ,我们通过插件解决

const globalVar = 'wx'
...
...
...
let contentObj = compilation.assets[file]
let code = contentObj.source()
code = code.replace(windowRegExp, that.globalVar);
contentObj = new RawSource(code)

compilation.assets[file] = new ConcatSource(
  contentSource,
  '\n',
  '\/**auto import common&runtime js**\/',
  '\n',
  contentObj,
);
复制代码

通过上述代码不难看出,我们读取了每个文件的源码,并将全局变量 window/global 替换为 wx ,再进行源码重组。

运行时文件引入

我们需要引入 runtime.js 和 common.js 文件, runtime 运行环境是webpack为每个编译文件插入的用于解析 define, require, module 等等这些的文件引入方法,为了精简文件,我们将之抽离为 runtime.js , common.js 为我们抽离出来的公共模块文件。在web/h5下引入这些资源是不是so easy,但你还记得我们是在小程序环境下嘛,并不能通过 <script> 标签来引入资源文件啊啊啊,你会不会猛拍脑门,一下就慌了(哈哈)。老办法,我们通过插件解决

const lens = []
let posixPath = ''
const matchIt = chunk.name.match(/\//g)
if (matchIt) {
  matchIt.forEach(it => lens.push(this.prePath))
  // posixPath = './'+lens.join('')
  posixPath = lens.join('')
} else {
  posixPath = './'
}
let posixPathFile = posixPath + 'runtime.js'
let contentSource = this.contentSource.replace('~~~~', posixPathFile)
if (chunk.name.indexOf('runtime') > -1) {
  posixPathFile = posixPath + 'common.js'
  if (hasCommon) {
    contentSource = this.contentSource.replace('~~~~', posixPathFile)
  } else {
    contentSource = ''
  }
}
复制代码

上述代码片段中, posixPath 是我们通过一个小的算法来推算资源引入的路径深度变量,输出并重写源文件chunk,这样我们就解决了资源引入的问题

webpack-dev-server

引入webpack-dev-server能够使得webpack的编译能够简单的输出到硬盘上,webpack默认是内存文件系统,并不输出(当然有其他方法,比如再写个插件或更换文件系统啥的),除了文件输出,webpack-dev-server还能够为我们提供mock数据服务,呵呵~,这里不展开了,大家有兴趣百度一下,还能够为我们访问后台接口作proxy,这里也不展开了。

通过上述操作,我们就能得到小程序结构的对等输出,剩下我们只需要将输出文件导入到小程序编辑器中,接下来就是开发工作了。嗯,这样就可以开始给小程序搬砖了,开心吗?

如果你想参考一下我们的编译代码,可以看这里 github.com/webkixi/aot…

如果你想了解下我们的架构,可以看这里 github.com/webkixi/aot…

如果你想使用我们的架构,怕不怕?怕的话,你看着办吧,哈哈! 不怕看这里 www.npmjs.com/package/aot…

如果你还想看看我们的小程序,看这里 developers.weixin.qq.com/community/d…

鲜花
鲜花
鸡蛋
鸡蛋
分享至 : QQ空间
收藏
原作者: 天天修改 来自: 掘金