Let's briefly introduce why we want to study the background of this issue. We hope we can customize our own implementation based on weex framework.js. The integration degree of weex has reached the warehouse of Vue. Learning this will also help us to understand the context of Vue.

Starting with package.json, five hooks related to weex construction can be found in scripts, namely:

"dev:weex": "TARGET=weex-framework rollup -w -c build/config.js", 
"dev:weex:compiler": "TARGET=weex-compiler rollup -w -c build/config.js",    
"build": "node build/build.js",    
"build:weex": "npm run build -- weex-vue-framework,weex-template-compiler",    
"test:weex": "npm run build:weex && jasmine JASMINE_CONFIG_PATH=test/weex/jasmine.json",    
"release:weex": "bash build/release-weex.sh",

Both dev and build environments point to build/build.js and build/config.js files, while release points to a shell script. Start with release to see what this script does:

set -e
CUR_VERSION=`node build/get-weex-version.js -c`
NEXT_VERSION=`node build/get-weex-version.js`
echo "Current: $CUR_VERSION"
read -p "Enter new version ($NEXT_VERSION): " -n 1 -r
if ! [[ -z $REPLY ]]; then
  NEXT_VERSION=$REPLY
fi
read -p "Releasing weex-vue-framework@$NEXT_VERSION - are you sure? (y/n) " -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
  echo "Releasing weex-vue-framework@$NEXT_VERSION ..."
  npm run lint
  npm run flow
  npm run test:weex 
  # build
  WEEX_VERSION=$NEXT_VERSION npm run build:weex  
  # update package
  cd packages/weex-vue-framework
  npm version $NEXT_VERSION
  npm publish  cd -  cd packages/weex-template-compiler
  npm version $NEXT_VERSION
  npm publish  cd -  
  # commit
  git add src/entries/weex*
  git add packages/weex*
  git commit -m "[release] weex-vue-framework@$NEXT_VERSION"fi

From the perspective of context, the first three lint flow test s are secondary, mainly from npm run build:weex, it seems that release has also come to build/build.js.

Continue reading the build/build.js file. There's not much to do. It's just a build script, get the parameters of the run through process.argv, and use rollup to start the build. In this file, there is a line of code: let builds = require('./config.js').getAllBuilds(), pause, continue reading the build/config.js file, you can see a large section of configuration information, find three related to weex, respectively,'weex-factory','weex-framework','weex-compiler', and you can also find the entry file from entry, there is an entry. That's easier to do.

(Suggestion: The first thing to learn is rollup construction)

Read from the build script, it uses Rollup to build, starting from entries, loads weex/framework directly, and refers to vue-runtime (core/index.js) here. It looks like the whole script is written in ES6, and all the internal references are short paths, guess it should be aliased. Back in the build directory, you can see the alias.js file, which can be used here. See many useful aliases:

module.exports = {
  vue: path.resolve(__dirname, '../src/entries/web-runtime-with-compiler'),
  compiler: path.resolve(__dirname, '../src/compiler'),
  core: path.resolve(__dirname, '../src/core'),
  shared: path.resolve(__dirname, '../src/shared'),
  web: path.resolve(__dirname, '../src/platforms/web'),
  weex: path.resolve(__dirname, '../src/platforms/weex'),
  server: path.resolve(__dirname, '../src/server'),
  entries: path.resolve(__dirname, '../src/entries'),
  sfc: path.resolve(__dirname, '../src/sfc')
}

(Note: This is easier to read than the flat way of building React)

Now that the weex framework entry file has been found and several key lines of code have been found in reading it, I think it should have something to do with the customized implementation framework.

const VueFactory = require('./factory')

In the createVueModuleInstance function:

const exports = {}
VueFactory(exports, renderer)
const Vue = exports.Vue

In the createInstance function:

Object.freeze(weexInstanceVar)// Each instance has a independent `Vue` mdoule instance
const Vue = instance.Vue = createVueModuleInstance(instanceId, moduleGetter)
const instanceVars = Object.assign({
  Vue,
  weex: weexInstanceVar,    // deprecated
  __weex_require_module__: weexInstanceVar.requireModule // eslint-disable-line
}, timerAPIs)
callFunction(instanceVars, appCode)

This is the key point for weex to run Vue, so the problem is that there is no obvious. / factory file in the platforms/weex directory, so where does this come from?

(Note: Stop here for a moment, no matter where this. / factory comes from, and keep looking down.)

In the createInstance function, the createVueModuleInstance is executed to suspend the Vue reference, while in the createVueModuleInstance function, it seems that the weex team has used Vue.mixin to extend.

(Suggestion: The second thing to learn, what is Vue.mixin?

An instance Vars is injected into the createInstance function, which is the object that can really be used in the weex container on the Native side.

(Suggestion: The third thing to learn is what the ghost is freeze and what the ghost is assign)

So far, the whole context is relatively clear, we can easily achieve customization after considering the latter.

But what is the VueFactory back above? You can only start with the build/build.js file. If it's also a parallel "file" after the build, it's most likely to point to the vue-runtime.js file (guess), but there seems to be something else. From the release shell script processing, we can see that it executes npm run build:weex, and the npm hook actually passes in ['weex-vue-framework','weex-template-compiler'] to the build/build.js file. Through this parsing, we can get the configuration list in config.js. The reason why we need to pass in an export is that finally there will be exports in this VueFactory. = Vue $2 is exchanged, which makes it clearer.

If you are interested in the construction of Vue, you can also feel the above context, read the whole library packaging path, for reading the source code, has great help.