I've tried to get the app version using version.ts and applying some changes to the scripts.js in the UI build but always resulted in undefined values. Any suggestions to get the version for the renderer process? 🙏

That's because it's running in the renderer process, and since we have context isolation enabled and node integration disabled, you cannot access to version.ts code.

However, you should have access to the electronBridge api within the window object, which provides a desktopVersion() method that returns a promise to the current version via the context bridge.

So something like this might work:

window.electronBridge.desktopVersion().then((version: string) => {
  global.sentry = setupSentry({
    release: version,
  }
})

I'm not sure if this file should go here or in the ui folder. It's difficult to judge.

If we stop calling the renderer version of setupSentry from lavamoat.ts, we could move both these files to the ui folder, although I'm not sure if typescript is supported there.

Brilliant! I will try using the Context Bridge.
I also had the same thought about moving it to UI folder but I didn't get @sentry/electron working with the main and renderer process so in the end, I had to split and call the main process into lavamoat.ts.
I could explore more alternatives to that but without initializing the main process the renderer process stop working 😞.

If sentry-install.js is injected even before compiled javascript bundles, do we still need to initiate Sentry here?

Oh nvm, sentry-install.js is not initiating Sentry at all.

It is. sentry-install.js calls setupSentry, which in turn calls Sentry.init(...).

Also we are already initialising Sentry in globals.ts, so we shouldn't initialise it here as well.

Yes, that's true @bergarces, I don't know why did I make my second comment :/

We have two sentries running now one from the extension covering background and extension UI and the Desktop app covering renderer and main processes.

But I think we have three right now.

• One that runs in the renderer process when the sentry-install.js runs.
• One that runs in the main process when you call Sentry.init here in lavamoat.ts.
• One that also runs in the main process when globals.ts is loaded here, which also runs Sentry.init with the same settings as the extension (since that one deals with the extension state and needs the filtering from the extension sentrySetup).

My argument is that we don't need the second here, we can just add that ipcMode: Sentry.IPCMode.Both to the one we are already initialising in the main process.

EDIT: Ok, this has to do with the fact the extension one might not be loaded if they have not agreed with sharing in the extension. I get it now.

I'm not sure what the ipcMode does, but it should be added through globals.ts Sentry initialisation.

The problem is that globals.ts calls the setupSentry.js from the extension. So you'd have to do something hacky such as hijacking the Sentry object we pass, and make it so that the Sentry.init(something) is a shim that calls (something) => Sentry.init({ ...something, ipcMode: Sentry.IPCMode.Both })

This is the renderer process Sentry setup. Nothing is sent through here yet as the errors are bubbling up to the main process.

We can worry about getting the filter right then.

This will need to be simplified when readPersistedSettingFromAppState returns boolean from the state.

As discussed:

• Desktop opt in must be enabled to send Sentry reports through desktop, always.
• If desktopEnabled exists and it is truthy, then we also need for the extension opt in to be true.

We had to restore some of the values so that they can be used in the sentry-install script for the renderer process.

I've got rid of the distinction between SENTRY_DSN_DEV and SENTRY_DSN that they use in the extension.

We can control if we pass a dev or a prod one in the CI pipeline.