johnlindquist / kit

Script Kit. Automate Anything.
https://scriptkit.com
MIT License
3.91k stars 138 forks source link

"@esbuild/darwin-x64" package is present but needs "@esbuild/darwin-arm64" #1306

Closed uniphonic closed 1 year ago

uniphonic commented 1 year ago

On an M1 Mac, getting this error out of the blue, in the ScriptKit UI, where the script I'm running has been running fine for months:

"Please fix the following errors and try again You installed esbuild for another platform than the one you're currently using. This won't work because esbuild is written with native code and needs to install a platform-specific binary executable.

Specifically the "@esbuild/darwin-x64" package is present but this platform needs the "@esbuild/darwin-arm64" package instead. People often get into this situation by installing esbuild with npm running inside of Rosetta 2 and then trying to use it with node running outside of Rosetta 2, or vice versa (Rosetta 2 is Apple's on-the-fly x86_64-to-arm64 translation service).

If you are installing with npm, you can try ensuring that both npm and node are not running under Rosetta 2 and then reinstalling esbuild. This likely involves changing how you installed npm and/or node. For example, installing node with the universal installer here should work: https://nodejs.org/en/download/. Or you could consider using yarn instead of npm which has built-in support for installing a package on multiple platforms simultaneously.

If you are installing with yarn, you can try listing both "arm64" and "x64" in your ".yarnrc.yml" file using the "supportedArchitectures" feature: https://yarnpkg.com/configuration/yarnrc/#supportedArchitectures Keep in mind that this means multiple copies of esbuild will be present.

Another alternative is to use the "esbuild-wasm" package instead, which works the same way on all platforms. But it comes with a heavy performance cost and can sometimes be 10x slower than the "esbuild" package, so you may also not want to do that."

I've tried to follow many of these steps, to no avail. Any suggestions?

Thanks!

johnlindquist commented 1 year ago

@uniphonic Hrmm, I'd be curious what caused this...

The easiest solution is:

  1. Quit Kit.app
  2. Completely remove the Kit SDK at ~/.kit: rm -rf ~/.kit

    🚨 If you're a new developer, please be EXTREMELY careful with rm -rf commands. They can easily wipe files off your hard drive and they're impossible to recover

  3. Open Kit.app and it will repair the SDK
uniphonic commented 1 year ago

Thanks! But unfortunately I'm still getting the same error. I tried both manually removing the ~/.kit folder, and doing it via the CLI command you recommended. Still same error is happening. And yes, I did quit out of ScriptKit each time beforehand.

Then I tried running some different scripts, and they run successfully it seems, even though they're very similar. Then I tried just renaming the script that was failing, and it now runs under a different name. If I go back to the script that I originally got the error on, it's still erroring. I had it under source control, so I rolled back to a previous version that I know was working before, and it's still getting the error as well.

Then I remembered something I've been seeing recently... it seems sometimes even though I modified the script, when I run it I'm not seeing the modifications. Sometimes I have to quit out of ScriptKit completely and re-open it, before I can see the updated version of the script working. Is there possibly some issue with my local ScriptKit cache of compiled files?

johnlindquist commented 1 year ago

@uniphonic

Is there any chance you ran an npm install in your ~/.kenv? It may have used your system's npm instead of ~/.knode/bin/npm and messed things up a bit.

Quit Kit.app, then try re-linking your ~/.kenv to ~/.kit

cd ~/.kenv
~/.knode/bin/npm i ~/.kit

A few users have also reported that pnpm seems to interfere when Kit is installing new packages.

Do you have any .pnpm files in your ~/.kenv? Those would need to be removed too.

uniphonic commented 1 year ago

That worked! Yes, I must have run an npm install in my .kenv, since I didn't realize it was any different from a regular project folder. Thanks so much!!

johnlindquist commented 1 year ago

@uniphonic Cool, glad that fixed it.

Reasoning...

It's critical that ~/.kenv/node_modules/@johnlindqust/kit is a symlink to ~/.kit

joeyvandijk commented 1 year ago

@johnlindquist I suppose you can verify this like Screenshot 2023-09-20 at 09 37 56 ?

I was using the get-color #eyedropper example from https://www.scriptkit.com/blog/script-kit-v1512-welcoming-our-ai-overlords and suddenly this broke. No code changes on my end. I followed the above steps:

But still it does not run as expected. I am running an Macbook Pro M1 Max setup and got the same error @uniphonic had. Any other things that have popped up since that I can try?

johnlindquist commented 1 year ago

@joeyvandijk I'm still trying to hunt down how this issue keeps popping up, I'm starting to think it's some sort of npm issue when dealing with how it resolves the architecture...

Here's another example of it being solved:

https://github.com/johnlindquist/kit/issues/1335

removed ~/.kenv/node_modules and used ~/.knode/bin/npm i ~/.kit to install them

After you remove ~/.kenv/node_modules, you re-install them like this:

cd ~/.kenv
~/.knode/bin/npm i

Hope that helps, please let me know if not.

joeyvandijk commented 1 year ago

Thanks @johnlindquist for the quick reply. What I noticed was that accidently removed my .kenv folder but found a backup from some months ago with ONLY the scripts/*.js files. I added those and suddenly my above mentioned get-color script suddenly worked. πŸ€·β€β™‚οΈ πŸ™ƒ

This means for me that it is not package.json / npm related but something is parsed wrongly and triggers this error? Just a tip, but at least it also worked for me again.

Keep up the good work...slowly I get addicted to be able to adjust Scriptkit to my liking. 😁

johnlindquist commented 1 year ago

@joeyvandijk

people have noticed the incorrect version of esbuild inside of their node_modules, so I'm still suspicious of something happening with npm...

skipadu commented 1 year ago

I have the same error, with the Apple M1 MBP, as in the topic/first post. The problem started yesterday after I tried to update my old script that I have been using. And another thing is that it remembers the script name still in the ScriptKit, but it has cleared the file contents now so it is empty. It was simple script to open certain apps, so no big loss there.

I have tried all the steps in this thread, still getting the same error; gathering them here:

  1. Quit Kit.app

  2. Completely remove the Kit SDK at ~/.kit: rm -rf ~/.kit

  3. Open Kit.app to repair the SDK

  4. Quit Kit.app again

  5. Re-install node_modules/

    cd ~/.kenv
    ~/.knode/bin/npm i
  6. Re-linking your ~/.kenv to ~/.kit

    cd ~/.kenv
    ~/.knode/bin/npm i ~/.kit
johnlindquist commented 1 year ago

@skipadu Any chance you want to try the Script Kit v2 beta to see if that sorts it out?

https://github.com/johnlindquist/kitapp/releases/tag/v1.99.1

I'm planning launching a release candidate in the next few days, then release v2 in early December.

skipadu commented 1 year ago

@skipadu Any chance you want to try the Script Kit v2 beta to see if that sorts it out?

https://github.com/johnlindquist/kitapp/releases/tag/v1.99.1

I tried that v1.99.1 just now. It seems that I'm able to run my scripts again. πŸ₯³ Thanks!