getSchema() failing in Coda UI, but succeeding on CLI 🤔

Making Packs
1

Working on some updates to my Copper Pack, and ran into this issue where my sync tables are broken in the Coda UI, but not on the CLI.

I’m working with the latest Coda SDK

  • npm install @coda/packs-sdk@latest --save
  • npx coda --version
    • returns 1.0.1

Running my sync from the CLI results in a successful 7-page sync.

  • npx coda execute Companies --fetch (Companies is my sync table formula)

Uploading with npx coda upload pack.ts and then running sync tables in the UI (with version set to Latest) results in the following error:

  • getSchema function failed
  • Overview: getSchema function failed: Unexpected token ‘||=’ [/var/task/bundle.js:1:32]

I’ve searched my source code and don’t have the characters ‘||=’ anywhere.

To add to the weirdness, my latest public release still works fine, and in the version I’m uploading I haven’t made any changes to pack.ts (where my sync table is defined and getSchema lives), nor to the schema generation formula (mine is called getSchemaWithCustomFields) that getSchema() calls out to.

Anyone experienced something like this? Thoughts on where to look?

2

Hi @Nick_HE - This is something we noticed recently and have submitted a fix for. Are you on the latest version of the SDK?

The core issue here is that we use the esbuild library to bundle up CLI code before sending it to our server. We weren’t setting a target for esbuild, so it was building assuming the latest version of JavaScript. Our Packs runtime only supports ES2020 though. esbuild made a change recently to use the ||= operator in their builds, unless you were targeting an older version. This operator works locally if you are on a new version of Node.js, but will fail when it gets to our runtime. Updating your SDK to a newer version where we set a target should resolve the issue after you re-upload.

2 Likes
3

Ok thanks! I did @latest which gave me 1.0.1. I see in the changelog there’s a 1.0.2 - maybe if I explicitly specify that it will work. Though it looks like 1.0.1 is where the fix was implemented, hmm. I believe I was using node 16 locally on my machine, maybe if I run it under 14 it’ll work. Will update with my results.

1 Like
4

Confirmed, explicitly specifying 1.0.2 with

npm install @coda/packs-sdk@1.0.2 --save

instead of

npm install @coda/packs-sdk@latest --save

was successful in resolving the issue. I didn’t change my local node version. Thanks!

1 Like