@glassnote/client 2.4.8 → 2.4.10

package/autoStart.js

@@ -220,35 +220,6 @@ class AutoStart {
         }
       }
 
-      // Remove existing plist if it exists
-      if (fs.existsSync(plistPath)) {
-        try {
-          // Use spawn instead of execSync to avoid blocking
-          const unloadProcess = spawn('launchctl', ['unload', plistPath], {
-            stdio: 'ignore',
-            timeout: 5000 // 5 second timeout
-          });
-          
-          unloadProcess.on('error', (error) => {
-          });
-          
-          unloadProcess.on('exit', (code) => {
-            if (code !== 0) {
-              console.warn('launchctl unload exited with code:', code, '(may not be loaded)');
-            }
-          });
-        } catch (error) {
-          console.error('Could not unload existing plist:', error.message);
-        }
-        
-        // Remove the plist file regardless of launchctl status
-        try {
-          fs.unlinkSync(plistPath);
-        } catch (error) {
-          console.error('Could not remove plist file:', error.message);
-        }
-      }
-
       const plistContent = `<?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
@@ -273,29 +244,30 @@ ${launchArgs.map((a) => `    <string>${a}</string>`).join('\n')}
         fs.mkdirSync(plistDir, { recursive: true });
       }
 
-      fs.writeFileSync(plistPath, plistContent);
-
-      // Load the launch agent asynchronously
+      // El plist NO se borra ni se recarga si ya dice lo mismo, y NUNCA se hace
+      // `launchctl unload`.
+      //
+      // Esto lo llama el main en CADA arranque. En macOS, cuando el que arranca es el
+      // propio LaunchAgent (o sea: al iniciar sesión, que es el caso normal), la app era
+      // el job de launchd: el `launchctl unload` de aquí abajo mataba el job, y con él a
+      // la app que lo estaba ejecutando. Medido: el cliente se abría al login y se moría
+      // a los ~3 segundos, antes incluso del primer chequeo de actualización, que es a
+      // los 5. Encima el agente quedaba descargado, así que ni `launchctl list` lo veía.
+      //
+      // Tampoco se hace `load` cuando el contenido cambia: `RunAtLoad` arrancaría OTRA
+      // instancia encima de esta —la app no tiene lock de instancia única— y el archivo
+      // nuevo lo lee launchd solo en el próximo login, que es justo cuando tiene que
+      // valer. Escribirlo es todo lo que hace falta.
+      let actual = null;
       try {
-        const loadProcess = spawn('launchctl', ['load', plistPath], {
-          stdio: 'ignore',
-          timeout: 5000 // 5 second timeout
-        });
-        
-        loadProcess.on('error', (error) => {
-          console.error('Error spawning launchctl load:', error.message);
-        });
-        
-        loadProcess.on('exit', (code) => {
-          if (code !== 0) {
-            console.warn('launchctl load exited with code:', code);
-          } else {
-            console.warn('macOS auto-start configured:', plistPath);
-          }
-        });
+        actual = fs.readFileSync(plistPath, 'utf8');
       } catch (error) {
-        console.error('Error loading launch agent:', error.message);
+        actual = null; // no existía
       }
+      if (actual === plistContent) return true;
+
+      fs.writeFileSync(plistPath, plistContent);
+      console.log('macOS auto-start configured:', plistPath);
 
       return true;
     } catch (error) {

package/bin/glassnote.js

@@ -52,14 +52,26 @@ function npmEnv() {
 // con otro entorno, y ahí `npm` no existe. La auto-actualización moría en "npm no se
 // reconoce como un comando" y nadie lo veía. Si no hay forma de resolver el npm-cli.js se
 // vuelve al shim de siempre.
-function runNpm(args, opts) {
+// Separado de runNpm a propósito: decidir CÓMO se llama a npm es una función pura, y por
+// eso se puede comprobar en cualquier sistema (scripts/test-update.js lo hace). Ejecutarlo
+// no. La regresión que hay que impedir es volver a `shell: true` con un array de
+// argumentos: Node no entrecomilla en ese caso y en Windows la ruta del prefix se parte en
+// el primer espacio —`C:\Users\Santiago Andrade\...`—, con lo que npm intenta un
+// mkdir de 'C:\Users\Santiago' y la instalación entera falla con EPERM.
+function npmInvocation(args) {
 	const nodeBinary = mode.resolveNodeBinary(process.execPath);
 	const npmCli = mode.resolveNpmCli(nodeBinary);
-	const base = { stdio: 'inherit', shell: false, env: npmEnv() };
 	if (nodeBinary && npmCli) {
-		return spawnSync(nodeBinary, [npmCli].concat(args), Object.assign(base, opts || {}));
+		return { file: nodeBinary, args: [npmCli].concat(args), shell: false, viaNode: true };
 	}
-	return spawnSync(NPM_CMD, args, Object.assign(base, { shell: IS_WIN }, opts || {}));
+	// Sin npm-cli.js localizable no queda más que el shim del PATH. Sigue sin shell:
+	// spawnSync con un array ya entrecomilla por su cuenta cuando no hay shell de por medio.
+	return { file: NPM_CMD, args, shell: false, viaNode: false };
+}
+
+function runNpm(args, opts) {
+	const { file, args: argv, shell } = npmInvocation(args);
+	return spawnSync(file, argv, Object.assign({ stdio: 'inherit', shell, env: npmEnv() }, opts || {}));
 }
 
 // userData tira de `uuid`, y este CLI corre también donde el árbol de dependencias no
@@ -772,4 +784,10 @@ function main() {
 	}
 }
 
-process.exit(main());
+// Requerido desde un test, el archivo NO debe correr nada: solo expone las piezas que
+// se comprueban. Como CLI se comporta igual que siempre.
+if (require.main === module) {
+	process.exit(main());
+} else {
+	module.exports = { npmInvocation, npmEnv, toSpec };
+}