给开源项目做贡献,一方面能够增加自己看源码的积累,另一方面也是对自身代码能力的检验。因为开源项目本身已经是完整的项目,对于开源项目我们能贡献的大概分三种(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
,在组件
使用不在messages的I accept {tos}.
时,将其错误解析为I accept [object Object].
{{ $t('Terms of Service') }}
整个issue中提到了formatFallbackMessages
这个配置,由于本人没有使用过,所以需要理解这个配置项,打开官网文档发现该配置中文部分是缺失的(目前已经补充)。fallback-interpolation文档
注意message中的key是带有占位变量的
const messages = {
ru: {
'Hello {name}': 'Здравствуйте {name}'
}
}
const i18n = new VueI18n({
locale: 'ru',
fallbackLocale: 'en',
formatFallbackMessages: true,
messages
})
当模板template如下时:
{{ $t('Hello {name}', { name: 'John' }}) }}
{{ $t('The weather today is {condition}!', { condition: 'sunny' }) }}
将会输出:
Здравствуйте John
The weather today is sunny!
该feature的作者原意是想以en
的翻译文案作为message,同时将en
的文案作为其他语言的key,这样在代码层面就可以很容易的理解多语言的内容。理解了配置项的含义后,我们的修复bug之路就可以迈进下一步了。
查看源码
首先我们查看项目的贡献文档(大多数项目都会有贡献说明文档),虽说文档上让开发者在个人项目的v8.x
分支编写,但我通常都会在v8.x
切出fix分支,这样更利于之后对该项目其他issue的贡献。
我看代码的流程通常是从调用方式开始看的,但是这是在组件
中使用,所以在源码中难以查找其调用方式,所以这次我们以配置项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
中我们找到了如何对
组件测试的方法:
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 Term of service.'
)
}).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 Term of service'
)
}).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贡献,这即是对开源项目的理解熟悉,也是对本身能力的提升。