chore: Adds vite-remove-console plugin

[johncowen]

This PR removes any console.log/info/warn/errors from any production builds (this includes our e2e testing). These calls are kept when in development, including the PR preview sites.

---

Currently these calls are also kept during CLI testing as they don't use vite as yet, but it would nice to remove them from there also so we can just use them for development purposes.

Note: I want us to keep removing/avoiding console.logs in code/git overall, as a rule we should not leave any of these things in the code at all. But sometimes/occasionally its useful to have console.error/info/warn during development in code/git. It also helps if any console.logs somehow find their way into production code.

Personally I'm unsure whether we should remove console.error at all as they can be useful to users when hitting a problem with the application, especially if our in-app UI error pages are not super explanatory, so happy to hear anyones thoughts on that.

I'm adding the plugin now, but we can always remove the error removal later if its not what we want.

Signed-off-by: John Cowen john.cowen@konghq.com

[netlify]

✅ Deploy Preview for kuma-gui ready!

Name	Link
🔨 Latest commit	0c02914
🔍 Latest deploy log	https://app.netlify.com/sites/kuma-gui/deploys/649d8577acbfe500071e3eca
😎 Deploy Preview	https://deploy-preview-1140--kuma-gui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[lahabana]

Confused about this. We should talk more

[kleinfreund]

One approach to answer the logging question would consist of two things:

• Disallowing certain types of console calls via linter rules. Generally, console.log and console.info should not be allowed. Also, provided we use the Logger service instead of console.error and console.warn, these, too, should not be allowed (see the following point).

• Using the Logger service for visibility into unforeseen error scenarios.

  In my opinion, this only makes sense if the Logger service isn’t disabled in any environment (it’s currently disabled in production). This is a little bit of a problem as not disabling it in production would surface non-error logs in the console (e.g. when we log interactions for the potential use with a service like Datadog Logs).

  Additionally this means we shouldn’t ever generally log errors that are already handled in the application (e.g. an API call resulting in a 404 which can be a perfectly valid scenario to which no attention should be raised either in the dev tools console or any monitoring services).

---

Example for an unforeseen error scenario:

Today, we have a couple of places where code like this can be found:

try {
  // ...
} catch (err) {
  if (err instanceof Error) {
    error.value = err
  } else {
    console.error(err)
  }
}

It’s almost guaranteed that err is an instance of Error. Exceptions from native code (e.g. JSON.parse('{')) and exceptions raised in our code certainly are. One could argue the else branch is an impossible case and we could simply use a type assertion to consume err as an instance of Error unconditionally. However, for the cases where for some reason a different error format appears (e.g. throw 'string'), we would run into issues. The else branch serves as a convenient mechanism to provide some basic visibility into such cases.

We should likely replace console.error with logger.error from our Logger service. That would improve visibility into that unforeseen error scenarios.

[lahabana]

I think I 100% agree with what @kleinfreund is explaining here! Disallow console.log and console.error with linters and when we need to log log with the logger so when this happens in SaaS we get the info.
IMO that's Much nicer than "transforming the code at build time"

[johncowen]

Oh hey, sorry I thought I'd made a comment here already 🤦

Disallowing certain types of console calls via linter rules. Generally, console.log and console.info should not be allowed. Also, provided we use the Logger service instead of console.error and console.warn, these, too, should not be allowed (see the following point).

I floated disallowing console.logs with linting when I first got here (it's what I personally am used to), and from what I remember there was a bit of pushback:

I use console.log for debugging all the time and this rule makes this a nuisance.

Since then we had the issue with the console logs being in the prod build. I figured this was an alternative that folks might not pushback on, sounds like opinion has changed @kleinfreund ?

If so, more than happy for us add linting instead if it's no longer an issue.

As for errors, its slightly different as we mostly want errors left in, so its kind of the opposite of the situation with logging:

• Logs: We don't want them, ever. So lets lint and use lint ignore if there is the very odd occasion where we absolutely must have one.
• Errors: As we can't throw in certain places, the next best thing is console.error. So when we use them we definitely do want them, and they are very unlikely to be added and left in by mistake.

The argument for using logger.error I think is a good one. But it also means we are going to need to inject logger nearly everywhere, which will probably be really tedious, especially if we then disable the error logging in prod.

The other thing to take into account (as I explain in the description) is that I personally feel that our users being able to open the JS console and see errors is really handy when it comes to reporting problems or even resolving their own user issues without needing to file an issue with us to find out they'd been holding something wrong. I know this opinion is controversial, so understand if folks aren't keen on leaving them in.

I think the other important thing is, even for me whilst working on the project I quite often hit something where it would be handy to see the actual error in console, but because we swallow errors all the time to report them with a very bare bones error GUI page that just says 'Error', it can be really hard out to figure out what the issue is.

So to sum up this evening, right now I wholeheartedly agree with linting for logs, not totally sure about errors still. I'll sleep on it and come back tomorrow, when we can either close this or discuss a little further. Sound good?

[kleinfreund]

Since then we had the issue with the console logs being in the prod build. I figured this was an alternative that folks might not pushback on, sounds like opinion has changed @kleinfreund ?

I want to make a clear distinction between "allowing console[method] in the code base" versus "using console[method] during development". My point was specifically about a general "no console" rule making the latter a pain. The linting for this should be done in a way where adding a console.log during development doesn’t cause linter warnings or errors and can be committed. We could add hooks to run linting with a stricter rule set on push events.

The argument for using logger.error I think is a good one. But it also means we are going to need to inject logger nearly everywhere, which will probably be really tedious, especially if we then disable the error logging in prod.

I don’t see the problem with that.

The other thing to take into account (as I explain in the description) is that I personally feel that our users being able to open the JS console and see errors is really handy when it comes to reporting problems or even resolving their own user issues without needing to file an issue with us to find out they'd been holding something wrong. I know this opinion is controversial, so understand if folks aren't keen on leaving them in.

If we want this, the solution would be simply to not disable the logger service in production specifically for error and warn type logs.

[johncowen]

We could add hooks to run linting with a stricter rule set on push events.

This was specifically what I was suggesting we do when we originally spoke (if you remember I wanted to add .eslintrc.dev.js for local/dev only rules).

I think the most important thing is, it now sounds like we want exactly the same thing. So probably best to move on from there.

Lets go with allowing console's locally, but adding commit hooks (or at the very least CI) to prevent accidental logging happening again. I would very much rather do it with two separate files instead so its clear where to add things if we need to do more things like this (similar to the no-used-vars rule).

On the errors:

If we want this, the solution would be simply to not disable the logger service in production specifically for error and warn type logs.

If we are leaving errors in all the time (we I would suggest we do), then why would you not just use console.error instead?

I think I'm going to close this PR and replace it with an issue for adding 2 configuration of linting, i.e. we can use log in dev but not in prod. Prod should be enforced either on commit with a commit hook (preferably) or at the very least in CI.

Error we can continue discussion, its not as pressing as making sure we never leave console.logs in the prod build again (which was the intention with this PR)

Let me know if that sounds ok to you and I'll close this up and go ahead and make an issue.

[kleinfreund]

If we are leaving errors in all the time (we I would suggest we do), then why would you not just use console.error instead?

Because going through the logger service allows us to hook those up to monitoring services more easily.

Let me know if that sounds ok to you and I'll close this up and go ahead and make an issue.

Fine by me.

[johncowen]

Because going through the logger service allows us to hook those up to monitoring services more easily.

I thought console.errors end up in monitoring services also without us doing anything extra? Is that not the case?

[kleinfreund]

I thought console.errors end up in monitoring services also without us doing anything extra? Is that not the case?

That should be the case, but I rather use the logger service as an explicit source for this.

[johncowen]

Because going through the logger service allows us to hook those up to monitoring services more easily.

Ok so if it is the case that console.errors are already hooked up without us having to do anything, just using console.error is easier in my eyes than using a custom logger that we have to inject everywhere.

but I rather use the logger service as an explicit source for this.

I still can't see a good reason not just just use console.error, but I can see reasons not to use a custom logger. Lets maybe continue this chat when we next sync. I'll close this up for now and make the linting/git hook issue for console.log.

[johncowen]

Closing in favour of using environment aware linting, which is what we all would prefer. The console.error discussion is still in progress and I don't want it to block adding something for logging.

[johncowen]

xref #1179

[johncowen]

I've had second thoughts on this and would like to reopen this or a similar PR (now or at a later date, I don't mind)

TLDR; Linting is to prevent us from accidentally adding console.logs this PR was to prevent us from console logging logs that had been added on purpose

---

Just to be absolutely clear, I really really want to add environment aware linting and I've made an issue to cover that. The thing is, I think this PR has been misled into a discussion about how we prevent accidental addition of console logs, and that is not what this PR was about.

Let me try to explain:

A few weeks back we changed our logging functionality to remove the DataDog integration, and replaced it with what was supposed to be development time only logging. If we'd have had linting at the time, these console logs would still have been added with lint ignores as we were adding them on purpose.

Unfortunately the logging was implemented completely in reverse, i.e. we were logging only in production instead of only in development. We spotted this bug too late, and the console logs ended up in the production binary. We pushed a fix but we specifically and importantly (for the context of this PR) wanted to prevent this from ever happening again, we specifically said we should prevent this from happening again.

In my eyes if we want to prevent this from happening again we can:

1. Add environment aware linting but do nothing else and hope that nobody makes the same "in reverse" mistake again, linting alone will not prevent this from happening. Honestly I would hope it would never happen again, but I can never be sure.
2. Add environment aware linting and use a build time console.log remover (this PR) to ensure that console logs added on purpose with the intention that that are only dev time logs never actually end up in a production build.
3. Add environment aware linting and use some sort of test time assertions to catch any console logs added on purpose with the intention that that are only dev time logs never actually end up in a production build.

I prefer point 2. As long as the plugin works as advertised, it is impossible for explicitly added console.logs to end up in production. With point 3, we might get something wrong again, or not test a certain code path.

I do not want to do point 1.

I hope folks can understand the background to this PR. Please let me know you thoughts, or if you want any clarification.

If at the end we want to go with point 1, thats fine with me as long as its not only my decision.

[lahabana]

Add environment aware linting and use a build time console.log remover (this PR) to ensure that console logs added on purpose with the intention that that are only dev time logs never actually end up in a production build.

Can you give an example of a log you'd only want at dev time? Also just to make sure does our logger have a "debug" level?