-
Notifications
You must be signed in to change notification settings - Fork 21
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
improvement: Add environment aware linting to prevent console.logs
being left in code
#1179
Comments
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. |
Still relevant |
This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed. |
A while back we decided we wanted a split linting environment (#1179) which we did alongside other improvements in #2545. Since then we've decided to stick to one single linting environment, i.e. the stricter one. But we still only want to apply fixes on pre-commit and not in CI (CI should fail not fix). --- I also noticed that: - We needed `console.info` (you can see usage in #2531), so aswell as adding that I changed the `console.log`s we used in a cypress config to use `console.info` instead. - `npm install` was being passed `--frozen-lockfile` which is a `yarn` argument, it should be `npm clean-install` Signed-off-by: John Cowen <john.cowen@konghq.com>
Description
We want to prevent console.logs from being left in production builds, but we do want to leave console.logs in the code whilst we are working.
We should make two different eslint config files so we can overwrite rules in a production/CI config via a development/local config.
The development config would disable or augment any console log rules (or other rules) in the production config, thus allowing adding console logs only during local development. This development config would then not be used in CI.
Additionally we should configure some git hooks to only run the production rules on commit, meaning they are unlikely to even reach CI. But if for whatever reason the git hook fails or does not get installed, then CI would catch any issues.
Also see #1140
The text was updated successfully, but these errors were encountered: