You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I imagine this is a bit of a corner-case, but minimally I figured it should be brought to the team's attention.
I'm in the process of integrating LWC local dev into Illuminated Cloud 2, and I also recently picked up a Surface Laptop 7 which uses ARM64 instead of x64. The Salesforce CLI's packaged Windows x64 installer works just fine, albeit a bit slowly -- it's actually much quicker to use an npm-based install which in turn uses the ARM64-native node distribution -- and the lightning-dev CLI plugin installs just fine into this x64-based CLI install. Note that it doesn't install when using the ARM64 node.exe:
More on all of that here for those who might be curious.
UPDATE: The portion of the issue below was just user error, but I think it makes sense to keep this around to allow the plugin to be installed on Windows/ARM64 machines.
Anyway, when I try to start the server, I get the following:
$ sf lightning dev app
Error (1): The requested resource does not exist
Any idea what might be happening? Of course, it starts just fine on my Surface Laptop 5 which has a more traditional x64 processor.
Is there any type of verbose logging I might enable that could help to track this down?
Thanks in advance for your assistance...
The text was updated successfully, but these errors were encountered:
Hi Scott, please log out of your org (using sf org commands) and try to authorize the org again for your sfdx project to see if that resolves your issue. Also, if you launch the command as DEBUG=* sf lightning dev app then you should see a lot of debug info being printed on screen.
Hi, @maliroteh-sf. Thanks for the quick response. I was actually able to get it working just fine now on the Windows/ARM64 config. The issue was my own...I was trying to use it against an org where the feature wasn't enabled. Last week during Dreamforce I was using a preview scratch org with the feature enabled; for some reason it didn't occur to me to set the same thing up on this new machine, so the error -- albeit pretty opaque -- was (presumably) just due to the org not supporting the feature.
Given that I'm successfully using it on Windows/ARM64, it would be great if you could fix the issue with installation of the plugin also mentioned above, though. My workaround is to temporarily substitute the x64 node.exe binary during plugin installation, but it'd be great for users of this (admittedly new) hardware/OS combination didn't have to apply such a workaround to install/use this new feature.
SCWells72
changed the title
Local dev server won't start on Windows / ARM64
Local dev server can't be installed on Windows / ARM64
Sep 23, 2024
I imagine this is a bit of a corner-case, but minimally I figured it should be brought to the team's attention.
I'm in the process of integrating LWC local dev into Illuminated Cloud 2, and I also recently picked up a Surface Laptop 7 which uses ARM64 instead of x64. The Salesforce CLI's packaged Windows x64 installer works just fine, albeit a bit slowly -- it's actually much quicker to use an npm-based install which in turn uses the ARM64-native
node
distribution -- and thelightning-dev
CLI plugin installs just fine into this x64-based CLI install. Note that it doesn't install when using the ARM64node.exe
:More on all of that here for those who might be curious.
UPDATE: The portion of the issue below was just user error, but I think it makes sense to keep this around to allow the plugin to be installed on Windows/ARM64 machines.
Anyway, when I try to start the server, I get the following:
Any idea what might be happening? Of course, it starts just fine on my Surface Laptop 5 which has a more traditional x64 processor.
Is there any type of verbose logging I might enable that could help to track this down?
Thanks in advance for your assistance...
The text was updated successfully, but these errors were encountered: