Is it possible to object instantiate in preload.ts?

[tight skiff]

As in title, here is the idea:

// preload.ts
import {contextBridge, ipcRenderer, shell} from "electron"
import {LocalStorage} from "./LocalStorage.ts";

contextBridge.exposeInMainWorld("electron", {
  settings: {
    getSettings: () => {
      const foo = new LocalStorage() // defined in electron/main dir
      return foo.getSettings()
    },
  },
  ...
})

mind you, I receive other objects without issues should I comment out new LocalStorage()

The error that drops in browser's dev tools
TypeError: Cannot read properties of undefined (reading 'isPackaged') which originates in attached image.

Am I missing something obvious ?

Part of vite's/rollup's config

export default defineConfig({command{) => {
  // ...
  return {
    // ...
    plugins: [
      // ...
      electron([
        // ...
        {
          entry: "electron/preload/index.ts",
          onstart(options) {
            // Notify the Renderer-Process to reload the page when the Preload-Scripts build is complete,
            // instead of restarting the entire Electron App.
            options.reload()
          },
          vite: {
            build: {
              sourcemap: sourcemap ? "inline" : undefined, // #332
              minify: isBuild,
              outDir: "dist-electron/preload",
              rollupOptions: {
                external: Object.keys("dependencies" in pkg ? pkg.dependencies : {}),
              },
            },
          },
        ]),
       ]
      }
    }

[fervent mortar]

there is no electron.app in preload

[tight skiff]

I guess that makes sense but... uh, even if my LocalStorage() class is fully empty and has no mention of app how would that still be related to the no app if it's preload

[fervent mortar]

and i dont think inlining electron is a good idea

[tight skiff]

what do you mean by inlining electron 👀 ?

[fervent mortar]

you have index.js file

which inline electron dependency

[tight skiff]

ah the sourcemap

I suppose it shouldn't matter if it's dev env right?

[fervent mortar]

inline means it place multiple js files into single big one

it matter because file is wrong

[tight skiff]

well but then again, if I comment out const foo = new LocalStorage() everything loads without any issues

[fervent mortar]

i dont know what LocalStorage is

[tight skiff]

empty class basically

class LocalStorage {
  private static _instance: LocalStorage
  
  static getInstance() {
    if (!LocalStorage._instance) {
      this._instance = new LocalStorage()
    }

    return this._instance
  }
}

export { LocalStorage }

[fervent mortar]

and where getSettings comes from?

[tight skiff]

added it as a placeholder method to showcase the idea

may as well be public getSettings() {}

[fervent mortar]

is it real preload file?

[tight skiff]

correct

[fervent mortar]

show browser window settings

[tight skiff]

    const preload = path.join(__dirname, "../preload/index.js")
    this.mainWindow = (await new BrowserWindow({
      title: "Main window",
      width: 1200,
      height: 800,
      minWidth: 1200,
      minHeight: 800,
      webPreferences: {
        preload,
        nodeIntegration: true,
        webSecurity: false,
      },
      frame: false,
      show: false,
    }))

to reiterate on the index.js, this is what vite creates if we include the whole rollup's plugin's electron obj

[fervent mortar]

show preload/index.js file

[tight skiff]

well it's uh, 26k lines of code as I'm refactoring the app from contextIsolation: false to contextIsolation: true

[fervent mortar]

and show your devtools console with errors

[fervent mortar]

and preload file

[fervent mortar]

i need js file

[tight skiff]

no shot I can manage to throw 26k.7k lines o:

that got me thinking though, should the preload.js be actually that large?

because it feels like the whole app is actually packed in it

[fervent mortar]

depends on what you throw into it

[tight skiff]

if this is what I have, no way that should produce 26k lines of code

[fervent mortar]

no

[tight skiff]

I do see packages code that I have in node_modules in it

basically first lines

granted, I do have ffmpeg/ffprobe exe files attached to dependencies

so that's why they are probably in preload.js

due to

rollupOptions: {
  external: Object.keys("dependencies" in pkg ? pkg.dependencies : {}),
},

which doesn't really matter I suppose? as the app loads without issues the moment I don't instantiate new LocalStorage() in preload.ts; wish I could understood why though

[fervent mortar]

its matter

[tight skiff]

at this point I may as well ditch the whole new Class() idea lol - looks nice from architecture perspective but it sure adds way too much headache

[fervent mortar]

why preload file is entry point?

[tight skiff]

happy to be corrected as I'm stitching things from different internet sources and some may be dated

[tight skiff]

@fervent mortar I didn't fix the issue (yet) but I see where the cause can possibly be with the new outlook on the preload.js - thanks for highlighting that and for your time

[fervent mortar]

You can try electron-forge vite template

[tight skiff]

using https://github.com/electron-vite/electron-vite-react

in the end I've sticked with

// preload.ts
contextBridge.exposeInMainWorld("electron", {
`getSettings: () => ipcRenderer.invoke('key')`
})

and in the react component

useEffect(() => {
  window.electron.getSettings().then(data => 
    setState(data)
  }
}, [])

i've put isLoading state in renderer until the promise finishes so the app loads appropriate preferences/settings without any contentful layout shifts

so to sum it up, trying with new Class() in preload.ts was a quite an overengineered approach