web-worker type export

[henrik-d]

Describe the bug

I'm using vite and get the following error in my typescript react project:
./node_modules/@bugsnag/web-worker/types/notifier.ts(17,10): error TS1205: Re-exporting a type when the '--isolatedModules' flag is provided requires using 'export type'.

Environment

• Bugsnag version: @bugsnag/web-worker": "^7.20.1"

[mclack]

Hi @henrik-d, I have attempted to reproduce the error you are seeing but have been unable to so far. Can I first confirm that you are definitely using bugsnag/web-worker within a web worker and not in another part of your app?

Can I also confirm how you are installing and using BugSnag? I.e: what commands did you run and are you using an import statement or require statement?

Any reproduction steps you can provide would be really useful. I think it would be especially handy to see your tsconfig.json file, but if you’re willing to share the files where you are attempting to configure and use BugSnag that would be great. You can write into support@bugsnag.com if there is anything you do not want to share on this public thread.

[henrik-d]

Hey @mclack

I'm using a custom logger class to report errors to bugsnag. I use this class inside my ServiceWorker and in my regular application. Therefore I'm using a dynamic import to import bugsnag.

// bugsnag.ts
export const Bugsnag = (
  typeof WorkerGlobalScope !== 'undefined' && self instanceof WorkerGlobalScope
    ? import('@bugsnag/web-worker')
    : import('@bugsnag/js')
).then((it) => it.default);

This is my Logger-class:

import { ENV } from '@/common/config';

import { Bugsnag } from './bugsnag';

export class Logger {
  // implement singleton pattern
  private static _instance: Logger;

  // eslint-disable-next-line @typescript-eslint/no-empty-function
  private constructor() {}

  static get instance() {
    if (!Logger._instance) {
      Logger._instance = new Logger();
    }
    return Logger._instance;
  }

  setUser(user: { id: string; email?: string } | null) {
    Bugsnag.then((bugsnag) => {
      if (user) {
        bugsnag.setUser(user?.id, user?.email);
      } else {
        bugsnag.setUser(undefined, undefined, undefined);
      }
    });
  }

  logError(message: string, error: Error) {
    console.error(message, error);
    if (ENV === 'production') {
      Bugsnag.then((bugsnag) =>
        bugsnag.notify(error, (evt) => {
          evt.context = message;
          evt.severity = 'error';
        }),
      );
    }
  }

}

And this is my tsconfig.json (generated by vite). The isolatedModules: true property causes the error.

{
  "compilerOptions": {
    "target": "ESNext",
    "useDefineForClassFields": true,
    "lib": [
      "DOM",
      "DOM.Iterable",
      "ESNext",
      "WebWorker"
    ],
    "allowJs": false,
    "skipLibCheck": true,
    "esModuleInterop": false,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "ESNext",
    "moduleResolution": "Node",
    "resolveJsonModule": true,
    "isolatedModules": true, // <-- this is causing the error
    "noEmit": true,
    "jsx": "react-jsx",
    "baseUrl": "./",
    "paths": {
      "@/*": [
        "./src/*"
      ]
    },
    "types": [
      "vite-plugin-pwa/client"
    ]
  },
  "include": [
    "src"
  ],
  "references": [
    {
      "path": "./tsconfig.node.json"
    }
  ]
}

My proposal would be to change in @bugsnag/web-worker/types/notifier.ts
export { WorkerConfig } to export type { WorkerConfig }, that would solve the issue for me.

[mclack]

Hi @henrik-d, thanks for that extra info. We’ve realised the issue here is that the file is not currently named as a .d.ts file, which would mark it as a type declaration file. This also follows the convention set by our other notifier libraries.

We will rename this file and schedule the update for our next release. In the meantime, you can either rename the file to end in .d.ts or change export { WorkerConfig } to export type { WorkerConfig } as you previously mentioned.

Thank you for bringing this to our attention. We will post an update on this thread once the fix has been deployed.

[Danetag]

@mclack Hey there! The issue seems to be persistent for me. Is it something expected?

[mclack]

Hi @Danetag

We haven't yet deployed any changes which cover this. Have you attempted the solutions as outlined above? I.e:

you can either rename the file to end in .d.ts or change export { WorkerConfig } to export type { WorkerConfig }