4 ms·

Yep, looks like you found the plugin! Note that if you're using Webpack 4, you won't need webpack-object-rest-spread-plugin anymore, since it uses the newest Ac

Yep, looks like you found the plugin! Note that if you're using Webpack 4, you won't need webpack-object-rest-spread-plugin anymore, since it uses the newest Acorn, which should handle object rest/spread syntax without needing a plugin. Annoyingly, Webpack still spends a lot of time parsing the JS files with its own parser, so you cut down on the transpile time but still need to do a relatively slow parse of all files. I've thought about making Webpack (or similar) use a fast parser like the one Sucrase uses, although it certainly seems like it would be a lot of work.

the_duke 8y ago
Do you have any benchmarks showing how much time is spent in on webpack plumbing vs babel, comparing to sucrase? As in, how much does this actually buy you in a real world scenario?
- alangpierce 8y ago
  I'm not very optimistic about webpack build times getting dramatically better with Sucrase in its current state. I've seen more clear benefits when running tests using sucrase/register. That said, I think it depends quite a bit on your webpack config. Certainly, if you run Babel single-threaded and don't cache the output, then you'll probably get a significant benefit, but that's likely not a realistic scenario. Some specific numbers I just measured for my codebase at work: Babel/TypeScript, cold cache: 66 seconds Babel/TypeScript, warm cache: 55 seconds Sucrase, cold cache: 52 seconds Sucrase, warm cache: 49 seconds This is on a codebase of about 400,000 lines of code (some JS compiled with Babel, some TypeScript compiled with tsc). Transpilation is parallelized using happypack (and I'm running it on a 4-core machine), but webpack parsing/processing is all single-threaded, so it ends up taking more time. I've done a little prototyping on using a Sucrase-like approach to speed up webpack (most of it is indeed parse time), but it would certainly be a project to get it working in practice. With a warm cache, it's not running sucrase/babel/typescript at all. I think the running time difference there is because Babel and TypeScript are emitting ES5, which is a little more code for webpack to parse. Probably a more correct comparison would be to configure Babel and TypeScript to target newer JS, but these should all be seen as rough numbers anyway.

the_duke 8y ago

Do you have any benchmarks showing how much time is spent in on webpack plumbing vs babel, comparing to sucrase? As in, how much does this actually buy you in a real world scenario?

alangpierce 8y ago
I'm not very optimistic about webpack build times getting dramatically better with Sucrase in its current state. I've seen more clear benefits when running tests using sucrase/register. That said, I think it depends quite a bit on your webpack config. Certainly, if you run Babel single-threaded and don't cache the output, then you'll probably get a significant benefit, but that's likely not a realistic scenario. Some specific numbers I just measured for my codebase at work: Babel/TypeScript, cold cache: 66 seconds Babel/TypeScript, warm cache: 55 seconds Sucrase, cold cache: 52 seconds Sucrase, warm cache: 49 seconds This is on a codebase of about 400,000 lines of code (some JS compiled with Babel, some TypeScript compiled with tsc). Transpilation is parallelized using happypack (and I'm running it on a 4-core machine), but webpack parsing/processing is all single-threaded, so it ends up taking more time. I've done a little prototyping on using a Sucrase-like approach to speed up webpack (most of it is indeed parse time), but it would certainly be a project to get it working in practice. With a warm cache, it's not running sucrase/babel/typescript at all. I think the running time difference there is because Babel and TypeScript are emitting ES5, which is a little more code for webpack to parse. Probably a more correct comparison would be to configure Babel and TypeScript to target newer JS, but these should all be seen as rough numbers anyway.