-
|
What are the node / npm requirements for witsy? I am trying to build/run with: npm: 10.9.2 but am getting a ERR_REQUIRE_CYCLE_MODULE error. Before checking further I just want to make sure my dev environment is sufficient… Thx! |
Beta Was this translation helpful? Give feedback.
Replies: 14 comments
-
|
My dev machine is: macOS: 15.3 (24D60) I know I run an outdated version of node 😀 Will try an upgrade once I release current WIP. Otherwise if you installed node through nvm, you should be able to try v20 and see if it works for you. Cheers |
Beta Was this translation helpful? Give feedback.
-
|
Thx! I played around a bit with node/npm versions - but always get the same error – so I am afraid it's not a tool version issue. I'm afraid a simple If anyone more familiar with Electron development would have a hint, I would be grateful! $ npm start
> [email protected] start
> cross-env DEBUG=1 electron-forge start
✔ Checking your system
❯ Locating application
✔ Locating application
❯ Loading configuration
Failed to load: /Users/.../witsy/forge.config.ts
✖ Loading configuration [FAILED: Cannot require() ES Module /Users/.../witsy/forge.config.ts in a cycle. (from /Users/.../witsy/node_modules/@electron-forge/core/dist/util/forge-config.js)]
(node:98510) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:98510) [MODULE_TYPELESS_PACKAGE_JSON] Warning: Module type of file:///Users/.../witsy/forge.config.ts is not specified and it doesn't parse as CommonJS.
Reparsing as ES module because module syntax was detected. This incurs a performance overhead.
To eliminate this warning, add "type": "module" to /Users/.../witsy/package.json.
An unhandled rejection has occurred inside Forge:
Error [ERR_REQUIRE_CYCLE_MODULE]: Cannot require() ES Module /Users/.../witsy/forge.config.ts in a cycle. (from /Users/.../witsy/node_modules/@electron-forge/core/dist/util/forge-config.js)
at ModuleLoader.importSyncForRequire (node:internal/modules/esm/loader:352:15)
at loadESMFromCJS (node:internal/modules/cjs/loader:1554:24)
at Module._compile (node:internal/modules/cjs/loader:1705:5)
at Object.loadTS [as .ts] (node:internal/modules/cjs/loader:1815:10)
at Module.load (node:internal/modules/cjs/loader:1458:32)
at Function._load (node:internal/modules/cjs/loader:1275:12)
at TracingChannel.traceSync (node:diagnostics_channel:322:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:234:24)
at Module.require (node:internal/modules/cjs/loader:1480:12)
at require (node:internal/modules/helpers:135:16)
at exports.default (/Users/.../witsy/node_modules/@electron-forge/core/dist/util/forge-config.js:140:26)
at async /Users/.../witsy/node_modules/@electron-forge/core/dist/api/start.js:44:35
at async _Task.taskFn (/Users/.../witsy/node_modules/@electron-forge/tracer/dist/index.js:58:20)
at async _Task.run (/Users/.../witsy/node_modules/listr2/dist/index.cjs:2063:11) |
Beta Was this translation helpful? Give feedback.
-
|
Have you kept package-lock.json?Electron forge version specifically is important (7.4.0). The GitHub actions build from “scratch” on Linux Windows and macOS so we should able to get you running 😀
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, everything as in the repo (I'm on fc62480 and my working copy is clean) Ahh - got it running now (stupid me, coming from fvm, used nvm wrong...) Now actually using node v20.18.1 and it's working fine 👍 Thx! I wanted to try to debug the text selection fetching - it's working rarely for me. Not never (so I can be reasonably sure it's not a permission or security settings issue), but very rarely. Must of the time Witsy complains that the text is empty (when I definitely have a selection). That Apple Script stuff is notoriously unreliable… |
Beta Was this translation helpful? Give feedback.
-
|
Does not work perfect for me but works most of the time. But I agree: if you find a more reliable way to do this I would be happy. One solution would be to write a native app in Swift for instance just for that text grabbing and have Witsy call it. Need to make sure the binary is Universal and signed as part of the packaging process. Happy to have a separate discussion on Apple Script. Also I never tested to switch but it is not impossible that the |
Beta Was this translation helpful? Give feedback.
-
|
I found the issue. The problem is that the Apple Script automations work by "pressing" certain modifier keys, which does not work if the user is actually still holding down others. So if you e.g. assign "Read Aloud" to CTRL-SHIFT-SPACE and press that, it is likely that CTRL and SHIFT will still be pressed when the Apple Script is executed and then "CMD-C" for "copy" won't work. When I tried and made sure to very quickly release all modifiers (after pressing the shortcut for e.g. "Read Aloud") it works fine. But when I stay on them just a bit too long, it fails. I forked witsy and implemented a waitForNoModifiers() in macos.ts – works nicely, although the Apple Script code is (as usual) horrible… Needs further thought on how to implement cleanly also for Windows and others ("nut")… Should I create an issue for this? |
Beta Was this translation helpful? Give feedback.
-
|
Hey, was looking at your method and after some measures it adds a significant delay in the the text grabbing. Raw measurements showed moving from an average of 240ms without the wait to 460ms with the call to Nevertheless, I still wanted to fix the problem you mention and I made the Will be included in next release but if you can give it a try that would be nice! |
Beta Was this translation helpful? Give feedback.
-
|
Hey, thx for looking into this! Yes, that AppleScript stuff is not only unreliable and ugly, it's also slooooow 🐌 I tried to tighten the AS code a little, but most of the time is lost in the imports ("use ...") that are needed to access the NSEvent stuff... Unfortunately your changes do not really mitigate the initial issue :( The core probem lies in the AppleScript line: tell application "System Events" to keystroke "c" using command downDoing this via AppleScript results in pressing and releasing the c key and the command key in addition to what ever the user is currently (still) pressing him/her self. That means that whatever modifiers are contained in the keyboard shortcut the user assigned to "AI Commands" or "Read Aloud" will very likely still be pressed when that AS code executes and therfore that code will not perform a "CMD-C" (for copy) but e.g. something like a "CMD-OPTION-SHIFT-C" instead. Depending on what ever that does in the current application it is unfortunately not enough to repeatedly do that again until the user releases the modifier keys - the damage is already done. In my case for example the resulting shortcut that this AppleScript code performs will result in the selection to be lost - so after that then even successfully performing the CMD-C will not help anymore... So I played around a little with Nut.js and it seems to do things very differently. For example this sequence: await keyboard.pressKey(Key.LeftCmd, Key.A);
await keyboard.releaseKey(Key.LeftCmd, Key.A);
await keyboard.pressKey(Key.LeftCmd, Key.C);
await keyboard.releaseKey(Key.LeftCmd, Key.C);will successfully perform a "select all" and "copy" on my machine (macOS 14.7.2/23H311), no matter what other modifier keys I am holding down at the time this executes. It seems to not perform "robo-key-hits" but intead insert keyboard events (including modifier states) into the event stream and thereby be independent of the physical keys that are actually currently being pressed. So maybe it would be better to move to Nut.js altogether? I'd be happt do give it a shot… |
Beta Was this translation helpful? Give feedback.
-
|
Ok latest commits should resolve the issue. Keep me posted! |
Beta Was this translation helpful? Give feedback.
-
|
Wow - that was fast - noice! 👍 Works much better now. Interestingly the "AI Command" works more reliably than the "Read Aloud". I see in the code that in the "AI Command" your have a loop that tries repeatedly for 2 secs until it works - I guess that would also be needed for "Read Aloud"? Or do the loop directly in Automator's getSelectedText()? It's a shame that these "try repeatedly until it works" techniques are necessary, but when doing UI automation that unfortunately is often the case :( |
Beta Was this translation helpful? Give feedback.
-
|
Good catch on readaloud. Will have the same retry as commands and we should be good! |
Beta Was this translation helpful? Give feedback.
-
|
Hey. Just noticed that the |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, works fine with Safari for me. import { keyboard, Key } from "@nut-tree-fork/nut-js";
async function selectAllAndCopy() {
await keyboard.pressKey(Key.LeftCmd, Key.A);
await keyboard.releaseKey(Key.LeftCmd, Key.A);
await keyboard.pressKey(Key.LeftCmd, Key.C);
await keyboard.releaseKey(Key.LeftCmd, Key.C);
}
await new Promise(resolve => setTimeout(resolve, 1000));
await selectAllAndCopy();Launched it, switched to Safari (during the 1 sec delay) and it nicely performed the "Select All" and "Copy"… Even entering text worked (albeit quite slowly). macOS 14.7.2 (23H311) |
Beta Was this translation helpful? Give feedback.
-
|
Hum strange it indeed seems to work... Not sure what happened. Will be in next patch release while I do some additional tests! |
Beta Was this translation helpful? Give feedback.
My dev machine is:
macOS: 15.3 (24D60)
node: v20.18.1
npm: 11.0.0
I know I run an outdated version of node 😀 Will try an upgrade once I release current WIP.
Otherwise if you installed node through nvm, you should be able to try v20 and see if it works for you.
Cheers