[bug]: Property 'generateSecuredApiKey' does not exist on type 'Algoliasearch'

[remihuigen]

Description

type definitions are missing for generateSecuredApiKey. This issue was also metioned in #1548

import { algoliasearch } from 'algoliasearch'
const client = algoliasearch('applicationId', 'adminApiKey')
const securedKey = client.generateSecuredApiKey({
  parentApiKey: 'publicApiKey',
  restrictions: {
    filters: 'visible_by:public'
  }
})

Property 'generateSecuredApiKey' does not exist on type 'Algoliasearch'.ts(2339)

Client

Search

Version

5.21.0

Relevant log output

[shortcuts]

Hey, on what environment is your application running? generateSecuredApiKey is only available from the node bundle, or for more modern frontend implementations fetch also offers it. If you are in a cloudflare worker or similar, the worker build also provides an implementation.

[remihuigen]

Well the ts error is popping up in local development. I'm using it in a nitro server route

The method itself works, both in node environment and in CF workers. So its just the types that are missing.

.

[shortcuts]

Would you mind providing a minimal reproduction if possible? From a simple node env it seems like the type is present https://github.com/algolia/api-clients-automation/blob/main/playground/javascript/node/algoliasearch.ts#L32 so I assume this is a resolution problem

[shortcuts]

Looking at https://github.com/nitrojs/nitro/issues/2242 which points to https://github.com/nitrojs/nitro/blob/7e13a51fe6cf005109fd5ab60015cb1b38380be9/src/options.ts#L542-L552, it seems like worker should resolve properly, but from the issue details, it might resolve to browser instead

[shortcuts]

Could you log client.transporter.algoliaAgent.value in your environment and show what it returns? the user agent should contain the build used

[remihuigen]

log output of client.transporter.algoliaAgent.value: Algolia for JavaScript (5.21.0); Search (5.21.0); Node.js (22.14.0)

See reproduction: https://stackblitz.com/edit/nuxt-starter-l3ypukxx?file=modules%2Fsearch%2Findex.ts

After installing the deps, line 19 of ./modules/search/index gives the typescript error

Please note that stackblitz node version is 18. I'm using v22 (as per logs above).

[shortcuts]

Pretty weird to see this UA as hovering the import shows the browser one: module "node_modules/.pnpm/[email protected]/node_modules/algoliasearch/dist/browser"

[benyaminl]

@shortcuts I also found this happening to NextJS with App Route in import { algoliasearch } from "algoliasearch/dist/node";

https://nextjs.org/docs/app/building-your-application/routing/route-handlers#convention

import { algoliasearch } from "algoliasearch/dist/node";

export async function GET() {
    // const algoliasearch = require('algoliasearch');
    const APP_KEY = 'RANDOM_KEY';
    const client = algoliasearch(APP_KEY, 'HAIYAH_WHAT_HAPPEND');

    const securedAppKey = client.generateSecuredApiKey('HAIYAH_WHAT_HAPPEND', {
        restrictIndices: 'demo_ecommerce',
    })

    return Response.json({ appKey: APP_KEY, securedAppKey });
}

I do see that https://github.com/algolia/algoliasearch-client-javascript/blob/main/packages/client-search/builds/node.ts#L59 It's available on node.

But upon resolving to /dist/node, it doesn't have the type helper of it. (or is it intended?)

EDIT: Strange thing is, other developer say it's available? https://github.com/algolia/algoliasearch-client-javascript/issues/1548#issuecomment-2381636539

Or is there anyway around for now so using App Route or anything fetch we can get the secured generated one time API Key?

EDIT 2: For now I use work around with server side rendering using PHP/Composer package, at least it work on the PHP. Hope this resolved soon or we can have different importing ways into typescript.

[notjosh]

fwiw it just seems to be a TypeScript error - the function is available at runtime. I'm using a fairly hacky workaround in my env until it's resolved, which works without any issues.

const algoliaClientWithHelpers = (client: unknown): SearchClientNodeHelpers => {
  if (
    client &&
    typeof client === "object" &&
    "generateSecuredApiKey" in client &&
    typeof client.generateSecuredApiKey === "function" &&
    "getSecuredApiKeyRemainingValidity" in client &&
    typeof client.getSecuredApiKeyRemainingValidity === "function"
  ) {
    return client as SearchClientNodeHelpers;
  }

  throw new Error("Algolia client does not conform to SearchClientNodeHelpers");
};

// set up client like normal:
const algoliaClient = algoliasearch(appId, searchKey);

// wrap the call to satisfy TypeScript
const newKey = algoliaClientWithHelpers(algoliaClient).generateSecuredApiKey({
  parentApiKey: parentKey,
  restrictions: {
    filters: '...',
  },
});

Can't promise it works on all runtimes or versions (I'm on 5.23.0), so ymmv.

[mmase]

Is this going to be fixed?

[remihuigen]

I'm (again) running into this issue in a completely different project, and a completely different environment. It's not entirely the same issue as discussed previously, where the types didn't resolve, but the generateSecuredApiKey method was available. This case it's the other way around: the types resolve, both the method isn't actually available

This project is using the algolia client in a Directus Extension. These extensions only run server side, but transporter.algoliaAgent is still set to Algolia for JavaScript (5.23.3); Search (5.23.3); Browser.

Based on the other comments in this issue, I'd say the environment detection is pretty buggy in general....

[VitaliyPotapov]

I also faced this problem in the NextJS project. The reason - NextJS sets moduleResoution: "bundler" in the tsconfig.json, that affects both client-side and server-side code. While for client-side it's totally ok, for server-side it breaks typings because it resolves to browser exports.

Here's a screenshot - note @algolia/client-search is resolved as @algolia/client-search/dist/browser, although it's expected to be used on server:

If I set moduleResoution: "node", the error goes away. It's because exports field is now ignored in the package.json of @algolia/client-search, and just main index.d.ts used that refers to /dist/node.

But usage of moduleResoution: "node" is explicitly discouraged by TS documentation:

It reflects the CommonJS module resolution algorithm as it existed in Node.js versions earlier than v12. It should no longer be used.

Proposed solution

It would be useful if @algolia/client-search export everything from ./dist with types (in a similar way as algoliasearch package does):

+  "./dist/*": {
+     "types": "./dist/*.d.ts",
+     "default": "./dist/builds/*.js"
+  },
  "./dist/builds/*": "./dist/builds/*.js"

Then I will be able to explicitly import from @algolia/client-search/dist/node in the server-side code without errors:

This would also let the algoliasearch package get fixed, so it can refer /dist/node directly in the node build:

- import type { SearchClient } from '@algolia/client-search';
+ import type { SearchClient } from '@algolia/client-search/dist/node';

Otherwise, importing from algoliasearch/dist/node actually imports from @algolia/client-search/dist/browser under the hood.

Current workaround

With the current version of @algolia/client-search (5.40.1) I can manually perform type assertion using SearchClientNodeHelpers type:

import { searchClient, SearchClient, SearchClientNodeHelpers } from '@algolia/client-search';

const client = searchClient('appId', 'key') as SearchClient & SearchClientNodeHelpers;
client.generateSecuredApiKey({ parentApiKey: 'key' }); // <-- no type errors!

[giladv]

this is also happening to me with tsc. last version. is this going to be fixed?