? 关于 Ant Design 圣诞彩蛋及其修复方式

zin 发布于 2018-12-25 ant-design 最后更新 2022-06-18 16:35 43 浏览

关于 Ant Design 圣诞彩蛋,起源自 2018 年 9 月 10 日我的一次提交:00aebeb 。代码实现会在 12 月 25 日当天给所有按钮添加积雪效果,并增加 Ho Ho Ho! 的浏览器默认提示信息。这完全是我个人的一意孤行且愚蠢的决定,是我的错误给大家造成了不良影响,非常抱歉。

如何修复这个问题?

影响范围:3.9.33.10.0 ~ 3.10.93.11.0 ~ 3.11.5

我们已经回滚相关代码并发布了修订版本:3.9.4、3.10.10、3.11.6,各位请更新至相应的版本即可。使用了语义化版本的直接重新安装 node_modules 并重新下载即可。

代码里还有其他彩蛋么?

没有。

未来还会有类似的问题么?

不会。我们是开源软件,请像这一次一样持续监督我们,你们的监督让开源社区更美好。

已邀请:

et_sed

赞同来自:

?

tet

赞同来自:

主意还是很不错的,某些场合算是很讨喜的小心思,以后记得给文档,你面向的是开发者,你无法为开发者面向的企业和客户负责。

matque

赞同来自:

抱抱

iullam

赞同来自:

彩蛋的本意是好的,我觉得把彩蛋弄成主动配置的,加上春节这些更丰富的元素供选择,我想这未尝不可~

zamet

赞同来自:

早上被投诉,现在系统停了,老板出去安抚客户了。

rsequi

赞同来自:

看成了“日本人”的一次提交,还惊了一下

nrerum

赞同来自:

已经被开了 感谢楼主让我提前回家过年 终于有时间好好陪陪父母了

et_et

赞同来自:

确实是一个一意孤行,愚蠢的决定

modit

赞同来自:

这个事件相当热闹啊!
吃瓜!!

frem

赞同来自:

现在在收拾行李.买好火车票了.明天就回家.

wmagni

赞同来自:

兄dei,你当时搞这出是咋想的啊?

iipsa

赞同来自:

评论都是相当的热闹

ket

赞同来自:

开发环境做一些彩蛋还是可以接受的,生产环境这么搞真的容易出事

xminus

赞同来自:

大佬,留个入口吧,我们还是有这种需求的

kalias

赞同来自:

建议节假日都加上,清明节墓碑,劳动节加个铲子什么的

oautem

赞同来自:

用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家

小事?惊喜变惊吓。这种东西取决于应用场景的 不适当的应用用了这个 你觉得是小事么

ehic

赞同来自:

用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家

你知道开源的协议是什么吗?不懂就去从头到尾读一遍.

tvel

赞同来自:

也就中国团队能做出这种事情了, 用的一点也不省心, golang?

jalias

赞同来自:

恭喜ant-design荣获2018年最佳泛娱乐化前端团队

lvel

赞同来自:

antd没关系,其实初衷是好的。只是没有考虑 到一些特殊情况。
我还是很喜欢这个彩蛋的。说实话

oest

赞同来自:

火车票都买完了,你跟我说这个???

gest

赞同来自:

用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家。
EDIT: 还能被downvote,只能说毕竟是中专生都能做的行业wwwwwww

这是小事?你真厉害

hvelit

赞同来自:

用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家。
EDIT: 还能被downvote,只能说毕竟是中专生都能做的行业wwwwwww

如果大家是中专生,那你可能就是小学生

svelit

赞同来自:

用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家。
EDIT: 还能被downvote,只能说毕竟是中专生都能做的行业wwwwwww

如果真有人因为宗教原因受到了严酷的伤害,你还认为是小事儿么?国际化的一个开源项目,搞什么宗教仪式,长脑子了么?

eet

赞同来自:

彩蛋很好,但希望在文档中加入说明。

adolor

赞同来自:

用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家。

脑子呢?

taut

赞同来自:

心疼,目测年终奖没了

cut

赞同来自:

可以做一些节日主题,让大家自由选择

nnihil

赞同来自:

这完全是我个人的一意孤行且愚蠢的决定

表示同情,但请再回答此次问题是如何出现的?团队有哪些监督审核,为什么没起作用?以后如何避免其他类似问题出现?

能回答这些大家才敢用,个人无法避免团队项目再出问题,只能靠规范严格的流程。

kqui

赞同来自:

挺喜欢彩蛋这个玩法。前几天测试测出来还有点惊喜,大家都觉得很欢乐。希望以后如果有彩蛋,不要这么明显的,可能影响客户使用体验的。比如一个简单的console.log('圣诞快乐');就很好

wanimi

赞同来自:

用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家。
EDIT: 还能被downvote,只能说毕竟是中专生都能做的行业wwwwwww

用的时候我点了star,我点了watch,我跟小弟们说这个东西靠谱,我在社区里帮助别人掌握这个库,你要说这不叫谢谢,怎么说,我得当面道谢?“屁点大”“本意”“小事”,无意造成的伤害就不是伤害?善意的欺骗就不是欺骗?

somnis

赞同来自:

心疼那位兄弟....

首先你确定是真的吗,我表示怀疑,不要把不可考证的事当真的去说

ksequi

赞同来自:

用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家

你知道开源的协议是什么吗?不懂就去从头到尾读一遍.

开源的协议里当然没有包含

用的时候没一个人说谢谢

难道就包含了

屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家

qquas

赞同来自:

想法不错,不过作为开源项目,还是要在文档上多做説明 一些和主体功能无关的功能 应该默认关闭

kex

赞同来自:

挺有意思的,如果能给开发者控制权就好了~

xid

赞同来自:

用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家。

看看你楼下,还觉得是屁大点事儿?

iaut

赞同来自:

彩蛋本身没问题, 可是要提醒开发者啊, 政府网站也出了,企业网站也有了, 今天你加个彩蛋别人不知道,明会不会加上其他东西??

in_ut

赞同来自:

用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家。

这是屁大一点事? 这么多 star 不是感谢团队难道是用来好玩的?脑子是个好东西,可惜你个舔狗并没有

qquas

赞同来自:

已经被开了 感谢楼主让我提前回家过年 终于有时间好好陪陪父母了

是真的?不是真的你就过分了,以后antd项目停止维护就有你的锅

dsed

赞同来自:

按钮上盖点雪,挺好看啊~

id_cum

赞同来自:

惊闻 antd 发生了 圣诞节彩蛋事件,赶紧去检查了一遍所有项目,还好版本都较低没有发生故障,去官网观摩了一下,button上的云彩的确够惊艳,说到云彩,我就想起筋斗云和孙悟空,明年年初,中美合拍的西游记即将正式开机,我继续扮演美猴王孙悟空,我会用美猴王艺术形象努力创造一个正能量的形象,文体两开花,弘扬中华文化,希望大家多多关注。

kodit

赞同来自:

已经被开了感谢楼主让我提前回家过年终于有时间好好陪陪父母了

是真的?不是真的你就过分了,以后antd项目停止维护就有你的锅

这都整上停止维护背锅了。

nquae

赞同来自:

哥们儿今年是不是要3.25了

ha

赞同来自:

居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。

  1. 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。
  2. 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了

lvel

赞同来自:

已经被开了感谢楼主让我提前回家过年终于有时间好好陪陪父母了

是真的?不是真的你就过分了,以后antd项目停止维护就有你的锅

这都整上停止维护背锅了。

网络暴力见的还少了?

zearum

赞同来自:

所以搞个什么机制加强一下code review?
总得有亡羊补牢的措施吧。

asaepe

赞同来自:

可怕

vomnis

赞同来自:

我觉得挺有意思的。

tqui

赞同来自:

居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。

  1. 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。
  2. 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了

是彩蛋,也应该是给客户的,给开发者是什么鬼?文档里说明下,加个开关不就好了,大家没准还为这功能点赞,不至于现在搞得这样。

ksequi

赞同来自:

居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。

  1. 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。
  2. 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了

不同意你的说法,就算添加彩蛋,也要在 changelog 里面体现吧。。。然后应该默认不开启作为可选项供用户选择吧。。。这次加的是彩蛋,下次是不是会加点其他什么东西?这次的事必定会导致信任危机。。。

kquis

赞同来自:

居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。

  1. 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。
  2. 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了

这不是自相矛盾?

不会有说明
不符合预期的行为开发者自己想办法

开发者怎么在问题出现之前发现问题?

wfuga

赞同来自:

居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。

  1. 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。
  2. 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了

你的用户是开发者,而不是我的用户,你绕过我给我的用户的彩蛋不叫惊喜叫惊吓

psed

赞同来自:

为这个彩蛋点赞!

caut

赞同来自:

居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。

  • 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了">

    1. 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。

  • 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了

  • 也就是说,以后用开源产品得通读代码了?
    是不是下一步就要求所有类库「自主可控」,只能使用有国标认证和实名备案的类库。

    ererum

    赞同来自:

    居然没让产品经理出来背锅(手动狗头)

    asaepe

    赞同来自:

    居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。

    1. 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。
    2. 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了

    你的用户是开发者,而不是我的用户,你绕过我给我的用户的彩蛋不叫惊喜叫惊吓

    同意,绕过开发者直接给用户就是惊吓

    ksed

    赞同来自:

    创意是好的 出发点愚蠢的 过程是快乐的 结果是不负责任的 还是做金融场景的公司 安全感都给不了用户

    hiure

    赞同来自:

    @jamieYou 提个 issue 看看

    isit

    赞同来自:

    创意是好的 出发点愚蠢的 过程是快乐的 结果是不负责任的 还是做金融场景的公司 安全感都给不了用户

    不就是按钮上加了点雪花吗?这咋不安全了?

    nsequi

    赞同来自:

    image
    其实这件事影响这么大 还有很重要的原因是 楼主没有预测到国家刚好在近期禁止洋节 事业单位本因起带头作用的...

    nin

    赞同来自:

    有想法是好的,但是在开源的产品中,信任最重要

    zhic

    赞同来自:

    惊喜变惊吓。。。

    datque

    赞同来自:

    2. unexpected

    彩蛋应该是对用户还说的,而不是对开发者!!!是否给用户彩蛋应该有库的使用者(开发)来决定;并且这么大一个开源库这么做只能说明愚蠢!

    qet

    赞同来自:

    所以。。。这个时候怎么没人拿出 LICENSE 来看看???

    https://github.com/ant-design/ant-design/blob/master/LICENSE

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
    MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
    NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
    LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
    OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
    WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

    The software is provided "as is", without warranty of any kind, express or implied, 
    including but not limited to the warranties of merchantability, 
    fitness for a particular purpose and noninfringement. 

    In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.

    ivel

    赞同来自:

    评论都是人才

    zcum

    赞同来自:

    监督……

    lqui

    赞同来自:

    居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。

    1. 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。
    2. 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了

    这不是自相矛盾?

    不会有说明
    不符合预期的行为开发者自己想办法

    开发者怎么在问题出现之前发现问题?

    1. 阅读的时候,或者至少在引用的时候,请使用完整的句子,如果你看不懂英文的话(术语我不想翻译),谷歌或者百度均可。
    2. 我一直说的是『不符合预期的行为』,而不是『问题』。(在你这个语境下)问题这个词本身是负面的
    3. 我描述的是遇到(而非遇到之前)不符合预期的行为后怎么做。

    cid

    赞同来自:

    帅锅局

    xipsam

    赞同来自:

    还是VUE好,楼上的各位大神,还是改用VUE开发吧。

    ieos

    赞同来自:

    来吃个瓜,哈哈~ 彩蛋还挺娱乐的~

    et_sed

    赞同来自:

    antd本身谈不上责任,但确实有些项目不适用这个效果,开发人员毫无防御准备。to C的还好,to B的少不了需要跟客户解释等后续问题,还有部分政府项目或者宗教信仰不同的族群开发的应用。不过如果能配置也是不错。

    zex

    赞同来自:

    用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家。

    如果客户也觉得屁大点事那就好了

    vomnis

    赞同来自:

    如果把彩蛋交给开发者自由配置(自由配置时间和显示方式)就好了,这个还是有需求的。辛苦后续完善一下,给框架再增添的色彩。

    hquia

    赞同来自:

    用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家。

    这话说的就很不妥,隔壁有个兄弟说的好,快渴死的时候给我一杯免费的水喝我很感谢,但在水里下毒就不对了。何况开源的核心绝对不是“爱用不用”。

    dsit

    赞同来自:

    最后是不是会冒出来一个 是临时工的关系

    kautem

    赞同来自:

    发来贺电

    godio

    赞同来自:

    哈哈哈 还好我司做的不是政府项目 心疼被开除和扣奖金的兄弟

    sunde

    赞同来自:

    圣诞和你有啥关系,我们是中国人,这么典型的文化入侵为什么要舔,外国人过我们的春节嘛,吃我们的饺子吗,就是人家外企的圣诞气氛,也没国企的浓,加个圣诞,皮一下,就那么开心吗,那么开心吗,那么开心吗

    phic

    赞同来自:

    居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。

  • 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了">

    1. 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。

  • 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了

  • 也就是说,以后用开源产品得通读代码了?
    是不是下一步就要求所有类库「自主可控」,只能使用有国标认证和实名备案的类库。

    我觉得可以有,很安全

    wsed

    赞同来自:

    大家都是开发者,可能觉得不会有什么问题或者不妥,但是我们把它应用到企业产品里面,这就很严重了。这样动态改变样式,让企业用户觉得是不是还有监听业务数据、会不会私自上传企业数据,这都很严重啊!

    beos

    赞同来自:

    是在作死:
    image

    vvelit

    赞同来自:

    还是VUE好,楼上的各位大神,还是改用VUE开发吧。

    ant-design有vue版本的兄弟

    eearum

    赞同来自:

    image
    其实这件事影响这么大 还有很重要的原因是 楼主没有预测到国家刚好在近期禁止洋节 事业单位本因起带头作用的...

    政府啥时候近期禁止过洋节了, 没看到这个消息, 我看你就不要再传谣了吧, 唉

    aut_id

    赞同来自:

    已经被开了 感谢楼主让我提前回家过年 终于有时间好好陪陪父母了

    你是真的皮

    saut

    赞同来自:

    此issues可以作为检测贴.....
    凡事支持这种彩蛋(or觉得没什么)的人都可以认为是如下的情况:
    1: 单纯的蠢(确实不知道,这种人还有救).
    2: 揣着明白装糊涂(这种人就是坏.).

    iullam

    赞同来自:

    可以试试Fusion Deign https://fusion.design/

    nautem

    赞同来自:

    有创意是好事。可以过一过咱们中国的传统节日。

    et_est

    赞同来自:

    不应该默认关闭吗,默认开启就有点流氓的感觉了

    dodit

    赞同来自:

    @chn-yang 你的消息来源真封闭啊

    gsint

    赞同来自:

    做为开源项目确实不应该,起码应该在文档中明确标注,并且默认关闭

    fet

    赞同来自:

    可以作为feature支持,切忌动态生效啊

    aet

    赞同来自:

    image
    其实这件事影响这么大 还有很重要的原因是 楼主没有预测到国家刚好在近期禁止洋节 事业单位本因起带头作用的...

    政府啥时候近期禁止过洋节了, 没看到这个消息, 我看你就不要再传谣了吧, 唉

    是有的,不过没有公开说,我们这边大学很多都不让

    et_id

    赞同来自:

    image
    码农和设计师的审美。。。。

    grem

    赞同来自:

    @chn-yang 你的消息来源真封闭啊

    呵呵, 拜托, 不要以谣传谣好吧, 什么时候禁止普通人过圣诞节了? 具体单位约束具体人我不想讨论, 对于那些普罗大众来说啥时候被禁止了, 有禁止都是你们单位的事, 请停止回复我

    kautem

    赞同来自:

    开源精神代表了要对自己的repo负责,既然项目会被其他的developer使用,类似彩蛋的东西应该广而告之并且由使用者来决定是否启用.
    如果这次的style做成了可配置项,而且提前在changelog告知,那我觉得会是一件皆大欢喜的事情,结果现在搞成了教科书级别的作死...

    gest

    赞同来自:

    where is tag 3.9.4, i can't found?

    west

    赞同来自:

    事情根本原因是在这个 feature 的考虑和 review 的问题吧。我觉得不是愚蠢,是不够谨慎而已。contributor 本身的初衷是好的,如果没有这种创新,哪有今天的的开源社区。但是,能力越大责任越大。Ant Design 本身具有非常大的影响力,作出任何修改,都要三思而后行。而且软件工程本身是一个迭代过程,有 bug 有错误决定都是过程上不可缺少的一环。KEEP GOING!??

    uet

    赞同来自:

    贯高,哈哈,尼玛,感谢送彩蛋

    lnulla

    赞同来自:

    别说了, 又是一个实习生搞的鬼, 已经被开了, 阿里的日常