Tag: homebrew

Salesforce CLI TypeError with node v. 25.1.0

This morning I kept getting "TypeError: Cannot read properties of undefined (reading 'prototype')" when trying to run any command with the Salesforce CLI. The version of node currently used is listed when you run a sf --version like below.

sf --version
@salesforce/cli/2.110.22 darwin-arm64 node-v25.1.0

After a bit back and forth the solution was to downgrade node.js from v. 25.1.0 to v. 24. I’m using homebrew so installing v. 24, and making the Salesforce CLI use it, was pretty straight forward once I knew (the brew link is required as npm will most likely use the newest version).

brew install node@24
brew link node@24 --overwrite

Once installed, run sf --version and it should show v. 24 like so.

sf --version
@salesforce/cli/2.110.22 darwin-arm64 node-v24.11.0

Once this was done the Salesforce CLI commands works just fine.

Note to self – script to update all my CLI stuff

npm_update_all_global() {
   npm list -g --json | jq ".dependencies | keys[]" -r | while read line; do
      npm -g update "$line"
   done
}
brew_update_all() {
   brew update && brew upgrade
}
heroku_update_all() {
   heroku update
}
sfdx_update_all() {
   sfdx update
}
lekkim_update_all_cli() {
   npm_update_all_global
   brew_update_all
   heroku_update_all
   sfdx_update_all
}

Use node.js LTS for Azure Functions

Did a proof-of-concept for an Azure Function in node.js that uses Redis Cache for session storage as the function runtime is 100% managed and using memory store doesn’t make sense. Once I had this I wanted to play with the local development support but that didn’t work as I was using node.js v. 13 and the Azure tooling only works an LTS version of node.js (meaning 12.x at the time of this writing). To fix I had to uninstall my current version of node.js and switch to v. 12.x as follows (I’m using Homebrew to manage dependencies):

brew uninstall node
brew install node@12

Then I had to update my PATH as the node binary is not in /usr/local/bin anymore but rather in /usr/local/opt/node@12/bin. Once that was done the Azure tooling for local application development worked like a charm.

The proof-of-concept is at https://github.com/lekkimworld/poc-azure-functions-with-session.

Running Mulesoft AnyPoint Studio on MacOS with homebrew

I’m using homebrew to manage many of the addons I use on my Mac. I had openjdk 12.0 installed previously but needed OpenJDK 1.8 to run Mulesoft AnyPoint Studio 7.4. Making that work I had to install OpenJDK 1.8 from adoptopenjdk (https://adoptopenjdk.net/) using homebrew and then tweak the ini-file controlling the AnyPoint Studio which is Eclipse based.

I started by downloading and installing Mulesoft AnyPoint Studio from Mulesoft. Then I installed openjdk 1.8 using homebrew.

brew tap AdoptOpenJDK/openjdk
brew cask install adoptopenjdk8

OpenJDK 1.8 was installed to /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk and the Java Runtime Environment could be found in /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre. Making sure it works is always a good idea.

/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/bin/java -version

Now edit the AnypointStudio.ini for and specify the Java Runtime to use using the -vm switch (in bold).

-startup
../Eclipse/plugins/org.eclipse.equinox.launcher_1.4.0.v20161219-1356.jar
--launcher.library
../Eclipse/plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.551.v20171108-1834
-vm 
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
-vmargs
--add-modules=ALL-SYSTEM
-Xms512m
-Xmx1024m
-XX:MaxPermSize=512m
-Dosgi.instance.area.default=@user.home/AnypointStudio/studio-workspace
-Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1
-Dsun.zip.disableMemoryMapping=true
-Dequinox.resolver.revision.batch.size=1
-Dmule.testingMode=true
-Dorg.mule.tooling.runtime.args=-XX:-UseBiasedLocking,-Dfile.encoding=UTF-8
-Dorg.mule.tooling.runtime.proxyVmArgs=-Dcom.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true
-Djdk.http.auth.tunneling.disabledSchemes=
-XX:ErrorFile=./studio_crash_report.log
-Dorg.mule.tooling.client.usecache=true
-Dtooling.concurrent.local.repository.enabled=false
-Dtooling.client.configuration.filter.parameters.reserved.names=false
-Dfile.encoding=UTF-8
-Djava.awt.headless=true
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts

Calling a Swagger service from Apex using openapi-generator

For a demo I needed to make calls to the Petstore API using a Swagger / OpenAPI definition from Apex. Unfortunately the Apex support that External Services in Salesforce provides is only callable from Flows so I needed another approach. Using openapi-generator and installing via Homebrew it went relatively smoothly anyway.

It’s always nice to stand on the shoulder of giants so the examples provided by Rene Winkelmeyer (Connecting to Swagger-backed APIs with Clicks or Code ) came in handy. Unfortunately didn’t work as the prefix for the generated classes was different plus the petId was was 1 and not 100. Anyway again easy to fix.

Below are my steps to get working using Homebrew and Salesforce DX.

$ brew install openapi-generator
$ openapi-generator generate \
     -i https://raw.githubusercontent.com/openapitools/openapi-generator/master/modules/openapi-generator/src/test/resources/2_0/petstore.yaml \ 
     -g apex \
     -o /tmp/petstore_swagger/
$ cd /tmp/petstore_swagger
$ sfdx force:org:create \
     -v my_devhub \
     -f config/project-scratch-def.json -a petstore_swagger
$ sfdx force:source:push -u petstore_swagger
$ sfdx force:apex:execute -u petstore_swagger
>> Start typing Apex code. Press the Enter key after each line,
>> then press CTRL+D when finished.
OASClient client = new OASClient();
OASPetApi api = new OASPetApi(client);
Map<String,Object> params = new Map<String, Object>();
Long petId = Long.valueOf('1');
params.put('petId', petId);
OASPet pet = api.getPetById(params);
System.debug(pet);
<Ctrl-D>