This PR proposes using rspack, a "webpack-compatible" js bundler, for dev and production builds of jbrowse2
The rsbuild ecosystem was relatively easy to swap out for our codebase
why change at all
reduced config
substantial speedups
why rspack?
rspack's high compatibility with webpack configs made it very easy to switch
it also allowed us to remove a lot of webpack config from the ejected cra config because it actually has many nice 'batteries included' features like typescript support, allowing us to remove a lot of babel config
made dev server, production builds, storybook, and full repo ci much faster
actually makes bundle size smaller (710kb -> 650kb for gff loading, 1.5Mb -> 942kb for alignments track)
This PR proposes using rspack, a "webpack-compatible" js bundler, for dev and production builds of jbrowse2
The rsbuild ecosystem was relatively easy to swap out for our codebase
why change at all
why rspack?
speed
**note: this included disabling
react-docgen
which was slow and seemed unused (?)why would we maybe not rspack/rsbuild
why not vite?
vite is arguably the most popular bundler, however we have trouble with it
Screenshot of vite giving an error:
vite branch of jbrowse-web https://github.com/GMOD/jbrowse-components/tree/vite_web2