Upgrade app to use Pinecone 3.0.x

[aulorbe]

Problem

We on the SDKs team have since published a new version of our Typescript client. This PR simply updates some dependencies in order to work with the new client + changes a couple import stmts that are required in order to work with newer code.

*****Note: this PR will only work once the client's upcoming patch release is pushed to npm (3.0.2). So, do not merge this until then.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Infrastructure change (CI configs, etc)
• Non-code change (docs, etc)
• None of the above: (explain here)

Test Plan

Everything works when launching this app into production via Vercel, with the newest Pinecone Typescript client code (not yet pushed to npm).

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1208129226784961

[aulorbe]

(CI failures should resolve once 3.0.2 is pushed to npm)

[rschwabco]

lgtm

[rschwabco]

Just curious - why this is required?

[aulorbe]

From what my IDE told me, since cheerio uses CJS not ESM, it does not have a default export for its functionality. It seems that the previous syntax might've worked for some users/IDEs, but for those using strict module resolution rules (e.g. needing to differentiate btwn CJS and ESM syntax), the old way of importing cheerio wouldn't have worked (it didn't for me). This new syntax is apparently the 'correct and intended' way to import CJS modules.

When I ask ChatGPT why exactly, it gave me this:

2. import * as cheerio from 'cheerio';
   This is the recommended syntax when importing a CommonJS module in TypeScript. It imports the entire module as an object, which is the correct approach for modules that don’t explicitly define a default export.

Here's why this is recommended:

CommonJS Modules: In a CommonJS module like cheerio, the export is an object (module.exports). When you use import * as cheerio from 'cheerio';, you are effectively importing that entire object, which is the correct and intended behavior.

Type Safety: This approach ensures that TypeScript understands the module is being imported as a namespace object, making the type system more accurate.

Why It Matters
Using import cheerio from 'cheerio'; with a CommonJS module might work because of TypeScript's compatibility features, but it's not technically correct, and it can cause confusion or issues in certain setups, especially when you’re bundling your code or using more strict module resolution settings.

Using import * as cheerio from 'cheerio'; ensures that your code is correctly handling the module import, particularly in environments that distinguish between CommonJS and ESModules.

I've been using pretty strict module resolution rules in another project that I'm bundling this app with, so it's likely a holdover from that.

[rschwabco]

lgtm - pending tests passing