Skip to content
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

option to use old logger behavior #1503

Open
RayGuo-ergou opened this issue Mar 5, 2025 · 2 comments
Open

option to use old logger behavior #1503

RayGuo-ergou opened this issue Mar 5, 2025 · 2 comments
Labels

Comments

@RayGuo-ergou
Copy link
Contributor

RayGuo-ergou commented Mar 5, 2025

Feature Request

Hi I saw the logger behavior changed from an utility that check the environment, if the environment is product no message logger to just javascript console.*.

It makes sense for error and warning but for debug/log I would rather not having them logged in production for example: https://github.com/wxt-dev/wxt/blob/main/packages/storage/src/index.ts#L406-L409, in production I don't want to have this logged as it might be used in content scripts, and some of my settings are secret which I don't want to take the risk to expose to the website that my content script runs on.

What do you think to revert the old log behaviors only for debug (perhaps log also ?). Of course logs in the dev server etc will remind the same.

It might not be a big issue, but for example sentry will overrid the console.* based on websites owners config.

Is your feature request related to a bug?

"N/A"

What are the alternatives?

I am doing a work around at the moment like

export const settingsStorage = (() => {
  const debug = console.debug;
  if (import.meta.env.PROD) {
    console.debug = () => {};
  }
  const store = storage.defineItem<Settings>(SETTINGS_STORAGE_ITEM_KEY, {
    version: 2,
    init: () => defaultSettings,
    migrations: {
      2: (setting: SettingsV1): SettingsV2 => {
        return defu(setting, defaultSettingsV2);
      },
    },
  });
  return store;
})();

Additional context

@aklinker1
Copy link
Collaborator

Oh, woops, yes, we should clean that up. I also saw that there's one more console.log that got left in that file as well.

I can disable the logs in production

@RayGuo-ergou
Copy link
Contributor Author

were these debug statement for your development🤔, now I am more thinking can completely remove the console log/debug, if the user want to know if a migration is done, can check the devtools. Only emit errors if the operation is unsuccessful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants