4 ms·
In addition to this, one reason the JS tools of today are relatively slow is because they all need to parse the code. Babel parses it to compile it, then ESLint
by dan15 7y ago
In addition to this, one reason the JS tools of today are relatively slow is because they all need to parse the code. Babel parses it to compile it, then ESLint parses it again to lint it, then Webpack/Rollup/Parcel parses it again to bundle it. A single tool that reuses the same AST representation for all three tasks has the ability to become a lot faster.
- _bxg1 7y agoYes and no. ESLint doesn't need to run at build time, and I assume that if you integrate Babel and Webpack via webpack "loaders", some amount of work is saved (just guessing though). That said, yours is the only good argument I've seen for building a monolithic solution.
- dan15 7y ago> I assume that if you integrate Babel and Webpack via webpack "loaders", some amount of work is saved (just guessing though) The Webpack babel-loader just calls Babel with the source code, it doesn't reuse Webpack's AST: https://github.com/babel/babel-loader/blob/master/src/index.js#L204 https://github.com/babel/babel-loader/blob/master/src/index.... It has to do it that way, since Babel could parse some syntax that Webpack doesn't recognise (like Flow or TypeScript annotations). Webpack loaders can even take non-JS input and produce JS output (eg. "svgr" takes SVG images and produces React components) so I don't think Webpack can even assume that the input is JS at that point.
- _bxg1 7y agoAnd yet when it comes time for Webpack to crawl import statements, it can do so across all different kinds of files coming in through their own loaders. So I'm wondering if Webpack gets presented with some kind of structured "imports manifest" by the loaders, in which case I think it could skip its own parsing step.