New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sort-keys: Cannot set property 'prevName' of null at SpreadElement #11402
sort-keys: Cannot set property 'prevName' of null at SpreadElement #11402
Comments
Thanks for the report, I can reproduce this issue. It seems like |
This bug is quickly detected by our fuzzer, but unfortunately we're not running the fuzzer as part of CI. I'm going to work on a PR to enable running the fuzzer in CI, at least to look for rule crashes -- this sort of issue has been happening too often. |
This commit turns on our existing fuzzer tool to run a small number of iterations when the user runs `npm test`. This is intended to prevent bugs like #11402 where a rule completely breaks when it encounters a particular syntax, but the author doesn't think to test for that kind of syntax. When there are no fuzzing errors, this adds about 5 seconds to the `npm test` time. (When there are fuzzing errors, it takes more time because the fuzzer does extra work to try to find the minimal config that reproduces the bug.) The fuzzer actually has two modes: "crash" (where it only tries to detect rule crashes), and "autofix" (where it additionally tries to detect cases where a rule's autofixer creates a syntax error). For now, this PR just enables "crash" mode, because I remember "autofix" mode had some false positives (although they might have been fixed due to parser upgrades).
This reverts commit fe9e652. We can reenable it once eslint/eslint#11402 is fixed.
This commit turns on our existing fuzzer tool to run a small number of iterations when the user runs `npm test`. This is intended to prevent bugs like #11402 where a rule completely breaks when it encounters a particular syntax, but the author doesn't think to test for that kind of syntax. When there are no fuzzing errors, this adds about 5 seconds to the `npm test` time. (When there are fuzzing errors, it takes more time because the fuzzer does extra work to try to find the minimal config that reproduces the bug.) The fuzzer actually has two modes: "crash" (where it only tries to detect rule crashes), and "autofix" (where it additionally tries to detect cases where a rule's autofixer creates a syntax error). For now, this PR just enables "crash" mode, because I remember "autofix" mode had some false positives (although they might have been fixed due to parser upgrades).
This commit turns on our existing fuzzer tool to run a small number of iterations when the user runs `npm test`. This is intended to prevent bugs like #11402 where a rule completely breaks when it encounters a particular syntax, but the author doesn't think to test for that kind of syntax. When there are no fuzzing errors, this adds about 5 seconds to the `npm test` time. (When there are fuzzing errors, it takes more time because the fuzzer does extra work to try to find the minimal config that reproduces the bug.) The fuzzer actually has two modes: "crash" (where it only tries to detect rule crashes), and "autofix" (where it additionally tries to detect cases where a rule's autofixer creates a syntax error). For now, this PR just enables "crash" mode, because I remember "autofix" mode had some false positives (although they might have been fixed due to parser upgrades).
Tell us about your environment
What parser (default, Babel-ESLint, etc.) are you using?
babel-eslint
Please show your full configuration:
Configuration
What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.
beemo eslint "./packages/superset-ui-translation/{src,test,storybook}/**/Translator.{js,jsx,ts,tsx}"
What did you expect to happen?
Lint completes successfully. It works fine with
eslint@5.13.0
What actually happened? Please include the actual, raw output from ESLint.
See more at Travis
https://travis-ci.com/apache-superset/superset-ui/builds/101145033
Are you willing to submit a pull request to fix this bug?
Just posted #11403
The text was updated successfully, but these errors were encountered: