evanw / esbuild

An extremely fast bundler for the web
https://esbuild.github.io/
MIT License
38.19k stars 1.15k forks source link

[Feature]: fine grained cache control for incremental api #1980

Open hardfist opened 2 years ago

hardfist commented 2 years ago

We heavily use js plugins on top of esbuild to build complex projects(less、css module、postcss and so on), esbuild is much faster than webpack in first full build, but esbuild is not faster than webpack on incremental rebuild since webpack has nice cache strategy for incremental rebuild. take loader for example, which supports cacheable, which is true by default, it can heavily reduce the cost in rebuild(this loader hooks is not called for unmodified file), and parcel has similar api cache-invalidation, I'm wondering whether esbuild could provides similar api for cache invalidate management. even though we could implement some cache strategy in js plugin, but it still takes some cost of go|js communication, which could be reduced by esbuild's internal cache invalidation.

const lessPlugin = {
  name: 'lessPlugi',
  setup(build){
    build.onLoad({filter:/\.less$/, args => {
       const contents = lessRender(args);
       return {
          contents,
          cacheable: true // the js plugin will never be called for unmodified less file
       }
   })
  }
}
hardfist commented 2 years ago

Even I caching every result of onResolve and onLoad, the plugin communication for large project is too high, so without caching strategy in esbuild it self, it seems not possible to solve incremental performance problem. In myproject, incremental rebuild needs to call 15651 plugin, even though the plugin does nothing, the plugin communication costs 800ms in my mac. image

so it seems that current incremental solution may not scale well.