meteor 1.7. now creates two versions of your app depending on the browser, which reduces bundle size and might improve performance, but the result is marginal in many apps, because a great part of the app code comes from node_modules (e.g. react, react-dom, moment, lodash, etc.).
This code is usually shipped as es5, so it can’t be delivered as “modern” ES, altough they are often written in modern ES (or typescript, etc.)
When the modern code is shipped, its sometimes possible to use it by symlinking it into the project
E.g. take the (great) uniforms package: https://github.com/vazco/uniforms/
you can symlink the source directory into your app: ln -s ./node_modules/uniforms/src ./imports/uniforms, but then you have to change all import statements from import X from 'uniforms' to import X from '/imports/uniforms', which can lead to errors, because you won’t notice, when you import somewhere directly from node_modules.
Question 1: is it possible to do this trick without changing the import statements?
Another problem arises if the source code isn’t “normal” modern ES, e.g. it can be typescript or has a lot of custom babel plugins, so that meteor’s babel can’t compile it properly anymore. Even if package authors would compile it to “modern” ES, which state should it be? ES2016, ES2018, ES2048, …?
Question 2: How can package authors describe how to compile their code? Should meteor read the package’s .babelrc?
In many webapps apps, many CPU time will be spent in view framework code like react, vue, angular or blaze. So these libraries would profit most from the better performance aspect of the “modern” transpiling (apart from a reduced bundle size), but we would require a modern build of these frameworks.
Question 3 how to use modern transpiling on react? are there es20xx builds of react available?
I think that’s a quite interesting topic, but it will need some changes in the whole ecosystem at some point and its cool to see that meteor pushes that forward!