Background: We have a large number of standing eslint violations in our
legacy frontends. Rather than fixing or amnesty-ing all of them, we've
opted to use a simple integer limit of violations. Exceeding this
limit causes the quality check to fail.
Before we moved eslint off of Paver [1], the limit was unreasonably
high (probably due to deprecations that removed violation-rich frontend
code). This was good, except for the fact that we essentially weren't
catching when new violations creeped into the JS code.
So, in [1], we lowered the limit down to the lowest possible value,
which we thought was 1285. However, we've found that this made the check
flaky-- turned out, we have been unintentionally double-counting various
violations due to the symlinks in edx-platform. Some of those symlinks'
existence is dependent on whether and how `npm ci` and `npm run build`
have been run. As a result, 1285 would pass in some contexts, and fail
in other contexts.
The fix is to simply add all the relevant edx-platform symlinks to
.eslintignore. This allows us to lower the violations limit to 734.
[1] https://github.com/openedx/edx-platform/pull/35159
3e9158e9a8