MO
Compare two string in a git-diff-like way, and also it generates a fancy looking in your terminal 
**Describe the bug** Sourcemap from `@jscpd/core` doesn't work, and source code is missing in chrome devtools "Source" panel **To Reproduce** Use chrome devtools to debug `@jscpd/core` **Expected behavior** See the...
Write the builders syntax by hand is really tedious, can we provide some package like `@babel/template` or add an online playground to convert the code to builders syntax. It will...
This is a great tool to help people file issue with more details. And I'd like to add this tool in rax cmmunity issue template to let people use envinfo...
带你打开 nut 极速构建的新世界大门（聊聊 spa 的动态构建，这件事只有我 nut 才能做）  ## 为什么只有 nut 可以做？ - 路由到本地文件的反向推导 - 应用容器和页面的隔离，应用容器可以独立于页面启动，页面可以延后加载，同时应用容器对路由/页面的生命周期有足够的控制权，可以决定何时执行 - 动态路由 细节未完待续，有时间写下，可以点下右边 subscribe，订阅这个 issue
前两天偶然间看到了Dan Abramov的一条twitter，twitter原文是这样的 > Don’t write “flexible” modules. No matter how you plan, you’ll miss some future requirements. Write modules that are easy to delete. 不要写太灵活的模块，因为**你永远无法预知未来的需求变化。不如写一些容易移除的模块** > This is why composition...
npm包发布策略
## npm给我们带来了什么 - 跨工程的代码复用 - 语义化的版本控制，修复bug或引入新特性，升级版本号即可 ## 一个or多个npm包 **前提是你即将维护的是一个庞大的代码库** 他们之间其实可以有一个先后顺序 **比较好的情况是** 保持单个npm包迭代的情况下，在各个工程中先使用半年到一年，等到api稳定，bug基本不存在后，再考虑合到一个npm包中去 后续有新的代码加入，也可以采用类似的模式，先在单个npm包的状态下使用一段时间，等到稳定后再合入主库，保证主库的稳定性 **这和git分支管理其实有点类似** ## 总结 如果你要开发一个很大的代码库，前期代码不够稳定的情况下，可以采取一个模块一个npm包的方式，等到收到足够的使用反馈，bug很少的时候再考虑合到一个npm包中，前期就合并为一个包也意味着更多风险和bug，而采用多包的方案，对用户而言，可以更安心地升级，升级风险明显更低了 另一种常见的方案是使用多个发布通道，比如一个stable通道，另一个beta通道，在beta通道接收到足够的反馈并测试用例完善后，再更新到stable通道 以上所说的其实都是如何保证代码稳定性，降低用户升级风险的手段 至于最终究竟是一个还是多个npm包，这点真不好说，像lodash就提供了一个包，也提供了[per method packages](https://www.npmjs.com/browse/keyword/lodash-modularized)，这两种方式其实都有自己各自的优势，具体还是看**使用者的需求**了 1. 如果是内部使用 在文档完善的前提下，多个npm包其实不存在什么明显的弊端 2. 如果是作为一个开源项目 外部用户肯定不想修复bug的时候细到每个npm包，**要追踪每个模块的某个bug在哪个版本修复，手动升级单个模块版本以便修复问题，这对使用者来说不够友好，存在成本** 如果内部模块需要快速迭代，但过程中又容易引入新的bug，维护模块的人没有足够的精力来保证包稳定性的情况下，多个npm包有它的优势，它对整体规划要求不高，每个模块拥有各自的里程碑，可以更快速地迭代，也可以独立发布，选择使用哪种方式的时候，可以综合考虑下
前端性能监控概览
## 概览 性能监控的数据一般分为两种 1. Field data (也叫做 RUM，Real User Monitoring) 2. Lab data ### Field data 即我们在用户侧统计到的性能数据 #### 优点 - 真实，能反映最终的用户侧的页面加载体验 - 能够结合一些业务指标进行分析 #### 缺点 - 受限于浏览器API，统计到的性能指标有限 - 一次性数据，无法调试（很难定位性能差的原因） ###...
> 以下都基于你对 nut 这个项目有一定了解的前提下 点我发车：[Nut-Project](https://github.com/fengzilong/nut) 这篇文章主要说下 nut 这个项目的缘起，以及对目前前端中后台现状的理解 在前端工程化日益完善的现在，框架的范围已经**不再局限于 runtime 了**，比如 一个 library、一个 js 或者 css 文件 如果你只是提供一个 runtime，**很多构建阶段的优化、特性都无法做到** 所以 nut 是一个整合了 runtime 和 构建 的框架 ## 为什么叫 nut nut...
## 引子 尤雨溪在 VueConf US 2018 上说过这样一段话 原文： > After vue-loader 15, vue-loader configuration problems are now webpack configuration problems 翻译： > 在 vue-loader 15 之后，和 vue-loader 相关的配置问题都变成了 webpack 的配置问题...