bjnewman
commented
1 year ago Worth noting that i tested removing the plugin on a more complex internal app and only saw a similar magnitude of speedup, not percentage. So for example if an app takes 25 seconds to start on existing workflow, the eslint plugin is still pretty close to 2.5-3 seconds which makes the speedup more significant on smaller apps. Also we should put together a benchmarking suite as part of the overall perf effort.
❓Question
During testing for a separate feature, we discovered that removing the ESLint plugin from the standard webpack build config reduced the startup time for the example app from roughly 11.5 to 9 seconds. This is a significant speedup and it raises the question of whether running the linter on every compile is the best default. See for example https://github.com/web-infra-dev/rspack/issues/2353 where it is suggested to run the linter separately in a post-build step - which seems reasonable to me.
options include 1. Waiting for the inevitable eslint rust/go successor to solve this for us and do nothing 2. Exploring alternate strategies to improve bundler performance 3. removing eslint plugin from webpack config and add the linting in some other place (post-build, pre-push, pre-commit, pre-receive on server side)? 4. remove eslint plugin from webpack config and don't replace it - let users be free to lint how they please prior to CI.
I would vote in favor of 3, and adding a working pre-commit and pre-push hook to the example repo and templates. Although i think just changing it to a webpack compiler post-build hook is also a reasonable compromise.
Also to discuss, should we consider the lack of eslint plugin support a blocker for any possible webpack alternatives? I vote no, as again i would be in favor of only using git hooks (without knowing the status of eslint support for any other bundler maybe this is only an rspack thing).