Package does not work in electron due to current checks of `IN_NODE`

[vitonsky]

The problem

I use PGLite in electron app on frontend side (renderer process with browser environment). I build code with WebPack with target 'web'.

Currently I have a lot of fatal errors like these

Uncaught (in promise) TypeError: (intermediate value).readFile is not a function

Failed to fetch extension: pg_trgm TypeError: r.createGunzip is not a function

It looks the problems is caused by current implementation of environment checks

pglite/packages/pglite/src/utils.ts

Lines 6 to 9 in a5d8a21

	export const IN_NODE =
	typeof process === 'object' &&
	typeof process.versions === 'object' &&
	typeof process.versions.node === 'string'

Renderer process in electron is a web environment with browser API and with no access to node API.
However, object globalThis.process is available at runtime with subset of node features.

As you can see above, currently IN_NODE will be set as true in case of process is available. So pglite thinks it runs on node and tries to use API that does not exist.

It lead us to fatal errors that crash our app that works around database.

The request

Current behaviour looks like a bug. Let's improve definition of IN_NODE to distinguish if node API is really available.

Renderer context actually may include node API in case flag nodeIntegration is provided. There are many reasons why app may be not able to enable this flag. In our app we can't because of security reasons and because of maintenance costs (our app may run in browser and in electron both).

So we should research how to detect electron and then update IN_NODE initialization code.

As additional measure to prevent similar bugs in future I propose to allow user to set their environment explicitly. Straight ways to implement this feature is

• Add option to PGLite constructor. This would be ideal solution from user perspective, but it would require us to forward this flag to a low level code that is may be not trivial
• Make this option global. It could be implemented enough trivial

We could add export to a @electric-sql/pglite with some object like env that would contain environment settings

export const env = {
  api: 'node'
};

export const IN_NODE = env.api ? env.api.toLowerCase() === 'node' : fallback();

User would run something like

import { env } from '@electric-sql/pglite';

env.api = 'node';

to set environment globally.

Alternatively we could just check value of some symbol like that

export const IN_NODE = globalThis[Symbol.for('pglite_env')] === 'node' : fallback();

If you know another way how to make code works in electron with no toggle flag nodeIntegration please tell about it.

[yusifeng]

You can use patch-package to modify node_modules/@electric-sql/pglite/dist/chunk-3WWIVTCY.js (note that the chunkjs filename may vary across different versions). As for how to make the modification, simply describe the issue clearly (for example, I directly provided your content to an AI), and the AI should be able to resolve it.

[yusifeng]

I'm providing the content of my file: @electric-sql+pglite+0.3.14.patch
diff --git a/node_modules/@electric-sql/pglite/dist/chunk-3WWIVTCY.js b/node_modules/@electric-sql/pglite/dist/chunk-3WWIVTCY.js
index 0000000..1111111 100644
--- a/node_modules/@electric-sql/pglite/dist/chunk-3WWIVTCY.js
+++ b/node_modules/@electric-sql/pglite/dist/chunk-3WWIVTCY.js
@@ -1,1 +1,1 @@
-var Fe=typeof process=="object"&&typeof process.versions=="object"&&typeof process.versions.node=="string"
+var Fe=(typeof process=="object"&&typeof process.versions=="object"&&typeof process.versions.node=="string"&&!(typeof process!="undefined"&&process.type=="renderer"))&&(typeof require!="undefined"?(()=>{try{const fs=require("fs");return typeof fs.readFile=="function"}catch{return false}})():false)

[vitonsky]

@yusifeng I figured out the problem reproduces on setup where node integration is enabled for electron window.

As workaround I've disabled node integration and forward some api subset manually via contextBridge API.

I still think it is good idea to let user specify environment, because there are many potential use cases where PGlite may be confused and work incorrectly.

Your advice with patch-package sounds good. I will try this tool to fix another problems that is not resolved yet by package authors, thank you. I've thought packages patches are feature of yarn, but now I see that patch-package may be used anywhere to address problems immediately. Nice tool.