给开源项目做贡献，一方面能够增加自己看源码的积累，另一方面也是对自身代码能力的检验。因为开源项目本身已经是完整的项目，对于开源项目我们能贡献的大概分三种（docs文档、bug、feature新特性），其中难易度为 docs < bug < feature，但我提倡入手的时候可以从修复bug开始，这样更利于熟悉项目的代码。
以下以我最近给vue-i18n的一次pr为例，展示下从issue到pr的整体流程。
查看issue
https://github.com/kazupon/vue-i18n/issues/779，对于一个反映bug的issue，我们首先需要确认下是否能够复现，该issue上面已经提供了复现链接；demo中设置了formatFallbackMessages: true，在组件<i18n>使用不在messages的I accept {tos}.时，将其错误解析为I accept [object Object].
<i18n path="I accept {tos}." tag="div">
<template #tos>
<a href="about:blank">{{ $t('Terms of Service') }}</a>
</template>
</i18n>
整个issue中提到了formatFallbackMessages这个配置，由于本人没有使用过，所以需要理解这个配置项，打开官网文档发现该配置中文部分是缺失的（目前已经补充）。fallback-interpolation文档
注意message中的key是带有占位变量的
const messages = {
ru: {
'Hello {name}': 'Здравствуйте {name}'
}
}
const i18n = new VueI18n({
locale: 'ru',
fallbackLocale: 'en',
formatFallbackMessages: true,
messages
})
当模板template如下时：
<p>{{ $t('Hello {name}', { name: 'John' }}) }}</p>
<p>{{ $t('The weather today is {condition}!', { condition: 'sunny' }) }}</p>
将会输出：
<p>Здравствуйте John</p>
<p>The weather today is sunny!</p>
该feature的作者原意是想以en的翻译文案作为message，同时将en的文案作为其他语言的key，这样在代码层面就可以很容易的理解多语言的内容。理解了配置项的含义后，我们的修复bug之路就可以迈进下一步了。
查看源码
首先我们查看项目的贡献文档（大多数项目都会有贡献说明文档），虽说文档上让开发者在个人项目的v8.x分支编写，但我通常都会在v8.x切出fix分支，这样更利于之后对该项目其他issue的贡献。
我看代码的流程通常是从调用方式开始看的，但是这是在组件<i18n>中使用，所以在源码中难以查找其调用方式，所以这次我们以配置项formatFallbackMessages为入口查看。
通过全局搜索查到，src/index.js的_warnDefault方法中有其配置的判断（且仅有这里有调用）：
if (this._formatFallbackMessages) {
const parsedArgs = parseArgs(...values)
return this._render(key, 'string', parsedArgs.params, key)
} else {
return key
}
_warnDefault是当获取不到相关key的时候进行调用，而在我们知道这个配置项的含义就是找不到key的使用使用翻译值当key，所以我们接着往下看this._render方法：
_render (message: string, interpolateMode: string, values: any, path: string): any {
let ret = this._formatter.interpolate(message, values, path)
// If the custom formatter refuses to work - apply the default one
if (!ret) {
ret = defaultFormatter.interpolate(message, values, path)
}
// if interpolateMode is **not** 'string' ('row'),
// return the compiled data (e.g. ['foo', VNode, 'bar']) with formatter
return interpolateMode === 'string' ? ret.join('') : ret
}
这段函数，message会经过formatter的interpolate方法，interpolate方法，以$t的调用来简单说明，会根据第二个参数的数据类型进行判断并组合，例如$t('hello {1}', {1: 'me'})会被编译为hello me、$t('hello {1}', ['me'])也会被编译为hello me，当然还有vnode的形式调用（v-html使用）；经过编译后会根据interpolateMode值进行不同的组合，这里我们看到_warnDefault中调用的_render是传递写死的string，通过查看其他_render的调用发现interpolateMode还能是raw。
测试
到这一步，我们怀疑可能是interpolateMode写死string的可能，为此我们可以写一个test函数，这段测试函数可以在原有的单元测试中添加，在test/interpolation.test.js中我们找到了如何对<i18n>组件测试的方法:
describe('included translation locale message', () => {
it('should be interpolated', done => {
const el = document.createElement('div')
const vm = new Vue({
i18n,
render (h) {
return h('i18n', { props: { path: 'term' } }, [
h('template', { slot: '0' }, [
h('a', { domProps: { href: '/term', textContent: this.$t('tos') } })
])
])
}
}).$mount(el)
nextTick(() => {
assert.strictEqual(
vm.$el.innerHTML,
'I accept xxx <a href=\"/term\">Term of service</a>.'
)
}).then(done)
})
})
我们就依葫芦画瓢，增加一个describe，设置formatFallbackMessages : true，i8n的path设置为带有参数的string：
describe('formatFallbackMessages', () => {
let i18n
beforeEach(() => {
i18n = new VueI18n({
locale: 'en',
messages,
formatFallbackMessages: true
})
})
it('should be interpolated', done => {
const el = document.createElement('div')
const vm = new Vue({
i18n,
render (h) {
return h('i18n', { props: { path: 'I am {0}' } }, [
h('template', { slot: '0' }, [
h('a', { domProps: { href: '/term', textContent: this.$t('tos') } })
])
])
}
}).$mount(el)
nextTick(() => {
assert.strictEqual(
vm.$el.innerHTML,
'I am <a href=\"/term\">Term of service</a>'
)
}).then(done)
})
})
之后我们通过修改_warnDefault中的interpolateMode为raw，输出符合预想，确实是这个参数的原因，然后我们就可以进行修复工作了。
修复
通过调用的源头发现，interpolateMode参数一直有传递进去，所以我们只要修改沿途调用的interpolateMode为传递的值，最后传递进_render就可以了。
if (this._formatFallbackMessages) {
const parsedArgs = parseArgs(...values)
return this._render(key, interpolateMode, parsedArgs.params, key)
} else {
return key
}
进行补充测试item和全量测试
补充item后，命令行跑npm run test，根据输出test:unit测试是跑通的，但是test:e2e报错，提示我安装jdk，当时我想着代码没问题就可以提交pr了。
提交pr
这里有个小技巧，在给element-ui贡献代码时我就发现，如果你在commit信息中添加相关的issue编号，也就是https://github.com/kazupon/vue-i18n/issues/779中最后的数字，那么在该issue中就会关联到你提交的commit（尽管这时你还没提交pr）。
提交pr后等待机器自动跑通test（现在开源项目一般都会有这一步骤），发现还是跑不通test:e2e，这时负责pr的老哥就过来指导我了：
惭愧惭愧，其实开源项目说明我是这时候才认真看的，根据要求修改后，我就尝试在本地跑通test:e2e命令，安装jdk后还是不能跑通，这令我很困惑毕竟单元测试也跑通了。
为此我尝试了俩种方式确认：
1.回退到我修改之前的版本，跑test:e2e命令，发现还是跑不通，那说明要不就我本地环境不一样，或者本身就跑不通。
2.在项目的pr页面查看我之前合并的pr，发现也是跑不通的，这时我就确定项目本身跑不通。
这样子我就尝试自己修复e2e测试，但无果；第二天我发现主分支由作者本人更新了，拉下来后发现是能跑通e2e测试，所以使用git pull vue-i18n v8.x --rebase命令后（vue-i18n是我自己设置的远程地址别名，--rebase能让我的commit延后到主分支之后），再次提交pr就可以了。
后话
同一天，项目作者合并了我的pr，这段修复流程应该就画上了句号。但并不，因为之前我们说过该配置没有中文文档，另外也有issue反映没有中文文档不好理解，所以我又提了一个pr用于docs文档补充（https://github.com/kazupon/vue-i18n/pull/785
）。
其实给开源项目做贡献，能够让我在下班后学习新编码结构和对设计模式的理解，也能让我暂时脱离对业务的编写情绪中（当然了，工作中有时候也会做优化相关的有意思的工作），所以我有空还是会上去贡献过的项目中看看issue，能否作出pr贡献，这即是对开源项目的理解熟悉，也是对本身能力的提升。
