Stefan Hesse
03/17/2022, 11:20 AMStefan Hesse
03/17/2022, 11:21 AMStefan Hesse
03/17/2022, 11:24 AMJason Bosco
03/17/2022, 1:19 PMStefan Hesse
03/17/2022, 1:23 PMStefan Hesse
03/17/2022, 1:23 PMStefan Hesse
03/17/2022, 1:24 PMJason Bosco
03/17/2022, 1:24 PMJason Bosco
03/17/2022, 1:24 PMJason Bosco
03/17/2022, 3:11 PM1.3.0-5
of typesense-js. Could you give it a shot now?Stefan Hesse
03/18/2022, 7:00 AMJason Bosco
03/18/2022, 1:16 PMDamian C
03/18/2022, 1:29 PMtypesense
, then you need to add a line to Typesense.ts re-exporting that type like we do for other types in the library. Think of this file similar the way you would a public api end point. It's the only way to access the library.
As always, chime in if you think something I said is off, but that should set us on a general path forward. I'll check back when I can. Thanks for reaching out!Stefan Hesse
03/18/2022, 3:03 PMimport { SearchResponseHit } from 'typesense/lib/Typesense/Documents'
I wouldn't care about the path, if my typescript compiler wouldn't typecheck all of typesense all the time. I think it's not a configuration issue on my site, but everything I import get's typechecked ( unless it's exported properly (that is my understanding) assuming this because all the vue types are not constantly typchecked))
Would import the types at the "root"-type file fix my issue?Damian C
03/18/2022, 3:32 PMStefan Hesse
03/21/2022, 2:50 PMJason Bosco
03/21/2022, 3:52 PMSearchResponseHit
has an export
before its definition in Documents.ts: export interface SearchResponseHit<T extends DocumentSchema> { ...
And I also see it being available in the types file in the build here: https://github.com/typesense/typesense-js/blob/d4094648b9c0b88fb8d6f62844d4bbd81bbdd94d/lib/Typesense/Documents.d.ts#L62
So re-exporting it from the main Typesense file would only allow you to change the path like this: import { SearchResponseHit } from 'typesense'
.
I'm not sure if that alone will be sufficient to resolve your issue?Jason Bosco
03/21/2022, 3:53 PMSearchResponseHit
into Typesense.d.ts in your node modules folder and see if that helps in any way?Jason Bosco
03/21/2022, 3:53 PMStefan Hesse
03/22/2022, 7:09 AMJason Bosco
03/22/2022, 6:21 PMJason Bosco
03/22/2022, 6:21 PMStefan Hesse
03/23/2022, 7:22 AMStefan Hesse
03/23/2022, 7:31 AMimport {DocumentSchema, x, y, z..}
Then the user can import them directly
Or I could do it like the error types:
import * as Errors from './Typesense/Errors'
The difference is that as a user I have to use the later as follows:
Errors.[TYPE]
Stefan Hesse
03/23/2022, 7:31 AMStefan Hesse
03/23/2022, 2:38 PMJason Bosco
03/23/2022, 4:51 PMIs there any reason why there is not typescript eslint installed?No particular reason. I thought eslint already took care of linting TS as well, until WebStorm started complaining about not being able to parse
import type
. That's when I learnt eslint needs a TS plugin separately. I was trying to set this up myself earlier this week, and paused it when it said something about a useless constructor, though it's valid Typescript to define class variables via a constructor. Paused the exploration there...
Thank you for taking care of this as well. I wonder why even unchanged lines are showing up as changed in Github PR diff though. Any ideas?Jason Bosco
03/23/2022, 4:53 PMhttps://typesense-community.slack.com/archives/C01P749MET0/p1648020690665759?thread_ts=1647516018.829819&cid=C01P749MET0Do you know if it's a common pattern to put all Types in a namespace like I did for Errors? If so, that feels cleaner to me, so we don't clutter the top level namespace?
Stefan Hesse
03/24/2022, 7:46 AM