Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: re-exports all types in algoliasearch #1080

Closed
nunomaduro opened this issue Mar 13, 2020 · 11 comments · May be fixed by #1284
Closed

proposal: re-exports all types in algoliasearch #1080

nunomaduro opened this issue Mar 13, 2020 · 11 comments · May be fixed by #1284
Labels
investigate on hold v5 Anything new v5 major related

Comments

@nunomaduro
Copy link

Today, types like SearchOptions, or Rule are not exported by the algoliasearch package.

People are actually importing them directly from the modular packages:

import { SearchOptions } from '@algolia/client-search';

Solution: re-exports all types, and types from modular packages, in algoliasearch and configure API Extrator to warn us about non exported types.

@Haroenv
Copy link
Contributor

Haroenv commented Mar 16, 2020

Yes, we should make sure that you don't need to reach into implementation details to be able to fully use the types (they aren't always inferred if you wrap the client e.g.)

@bodinsamuel
Copy link

Yes please

@pinkfish
Copy link

+1, this took me quite a while to work out why I couldn't import things directly from algoiasearch.

@wiesson
Copy link

wiesson commented Jun 23, 2021

Any update to this topic?

@Haroenv
Copy link
Contributor

Haroenv commented Jun 23, 2021

Reopening the pull request, I lost track of it. Thanks @wiesson !

@wiesson
Copy link

wiesson commented Jun 23, 2021

@Haroenv no problem :)

I kind of solved it for now:

import type { RequestOptions } from "@algolia/transporter";
import type { SearchOptions } from "@algolia/client-search";

// hacky attempt to remove readonly
type Mutable<T> = { -readonly [P in keyof T]: T[P] };

(...)

let requestOptions: Partial<RequestOptions & Mutable<SearchOptions>> = {
  hitsPerPage: resultsPerPage,
};

if (page) {
  requestOptions.page = page;
}

if (lat && lng) {
  requestOptions.aroundLatLng = `${lat}, ${lng}`;
  requestOptions.aroundRadius =  radius * 1000;
}

if (boundingBox) {
  requestOptions.insideBoundingBox = [boundingBox];
}

const { hits, nbHits, page, nbPages } = await searchIndex.search(q, requestOptions);

(...)

@danielpl10
Copy link

This is still an issue, two years later after the first request. The current version of algoliasearch still doesn't have access to types, we need to install several unnecessary packages only for types. Any progress on this?

@Kraloz
Copy link

Kraloz commented Jan 30, 2023

Any workaround on this issue?

@Haroenv
Copy link
Contributor

Haroenv commented Jan 31, 2023

All types are exported, but from other packages, like @algolia/client-search, so you can look into the reference and find the import that way.

@shortcuts
Copy link
Member

shortcuts commented Sep 11, 2024

done in v5

@ryanjwilke
Copy link

@shortcuts Is this issue also related to this error that I'm getting locally and in CI? This started happening recently and it's a bit confusing as to what might have triggered this issue.

Here's the log output I'm seeing from CI:

(node:1783) ExperimentalWarning: Importing JSON modules is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
file:///home/runner/work/cypress.io/cypress.io/node_modules/algoliasearch/dist/node.js:54
import { EventType } from "@algolia/client-personalization";
         ^^^^^^^^^
SyntaxError: The requested module '@algolia/client-personalization' does not provide an export named 'EventType'
    at ModuleJob._instantiate (node:internal/modules/esm/module_job:146:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:22[9](https://github.com/cypress-io/cypress.io/actions/runs/11487393453/job/31972113009#step:6:10):5)
    at async ModuleLoader.import (node:internal/modules/esm/loader:473:24)
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:123:5)

It would appear that this issue is stemming from inside the package, but I could be wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
investigate on hold v5 Anything new v5 major related
Projects
None yet
9 participants