很好的 issue，关于按需引入，我的思路是这样的。
按需引入的最好做法就是保持代码无副作用，然后利用构建工具的 tree shaking 能力。但是保持代码副作用最基本的就是 杜绝任何使用别名去替代函数片段，又点绕口，举个栗子清晰一些。比如实线一个数据处理器：
export function process(processors) {
return (data) => {
processors.forEach(p => {
p(data);
});
}
}
export function double(data) {
return data * 2;
}
export function add1() {
return data + 1;
}
那么使用的时候：
import { process, double, add1 } from 'xx';
// 使用内置的 processor 或者自定义
const p = process([double, add1, (data) => data - 1]);
这是非常合理的设计，但是存在问题的就是，但我们尝试使用描述性的方式（spec，这个是 G2 5.0 后续会暴露出去的）去表达的时候：
{
data: 100,
processors: [{ type: 'double' }, { type: 'add1' }, { type: 'sub1' }]
}
为了 让这些函数片段可以用别名描述，我们会给每一个函数片段增加一个名字或者 id，所以额外也会增加一个 API
export function register(name, processor) { /**/ }
这样的技术设计是几乎所有的库都会使用的，包括上述你举例的 echarts，这个做了之后，对于按需其实完全可以做成一些工具去实现。
不过，道理都是上面的，按需都不是难事，难的是不同的 processor 如果有互相依赖，开发者怎么知道？所以对于 G2 来说，有非常非常多，看 stdlib 这个文件。这里面上百个的 lib 理论上都可以按需引入。
如果让开发者手动去按需引入，这个难度很高，即时做了在线的工具，也需要能梳理各个 lib 之间的依赖关系。所以当前我们还没有把按需引入在文档中透出。
@GitHubJackson 结论在这里：目前的包大小还是在可接受范围内，在正式版本发布之后，我们会评估，stdlib 中上百个模块做按需能节省多少包大小，如果是可观的，我们会继续去提供按需的方案。
另外，可以设想一个更好的方案，我们的架构设计中，stdlib 中的 type 是足够统一的，所以我们可以类似的 babel-plugin-import 一样，提供一个构建工具，自动识别代码片段中使用的 stdlib，然后转化成按需引入的代码片段。@pearmini
IssueHunt
