feat: Typescript#23
Conversation
leandrohlsilva
left a comment
There was a problem hiding this comment.
LGTM given comments
| /** API endpoint */ | ||
| endpoint: string | null; | ||
| /** HTTP method */ | ||
| method: 'get' | 'GET' | 'post' | 'POST' | 'put' | 'PUT' | 'patch' | 'PATCH' | 'delete' | 'DELETE'; |
There was a problem hiding this comment.
Why not just uppercase?
There was a problem hiding this comment.
Just keeping parity with how fetch itself works
There was a problem hiding this comment.
Whilst this is a reasonable goal, I don't think we don't need to strive for fetch parity here. I'd go for one or the other - flexibility is the devil!
There was a problem hiding this comment.
Haha happy to fix it to uppercase
| export type RequestConfig = { | ||
| /** API endpoint */ | ||
| endpoint: string | null; | ||
| /** HTTP method */ |
There was a problem hiding this comment.
These comments are irrelevant and can be removed.
There was a problem hiding this comment.
I would digress, these comments show up in the hover popup in IDEs, so lets leave these here. Can be filled with useful info later on
There was a problem hiding this comment.
Yes. Hover wil show it. U can even put code snippets in these
Co-authored-by: Leandro Silva <leandrohlsilva@gmail.com>
Co-authored-by: Leandro Silva <leandrohlsilva@gmail.com>
|
BTW I forgot to add, to be able to take advantage of this, tsconfig of the consumer projects will have to be changed to not ignore the node_modules. It didn't break anything, just starts including type data from node_modules which is precisely is what we need here |
antony
left a comment
There was a problem hiding this comment.
Just adding some comments. I think it's hard to vote with approvals, so I'd suggest a thumbs up or thumbs down as go/no-go
| "test": "mocha './!(node_modules)/**/**.+(spec).js'", | ||
| "lint": "eslint lib --ext .js" | ||
| "lint": "eslint lib --ext .js", | ||
| "compile": "tsup" |
There was a problem hiding this comment.
I'm confused at the concept of no build step, but there is a compile step here
There was a problem hiding this comment.
No no, it can have a build or no-build. Its what everyone shud decide. I wrote up in the description
There was a problem hiding this comment.
Not sure compile is the right word here. I'd suggest build instead
There was a problem hiding this comment.
Replaced it with build
| "node": "18.15.0" | ||
| }, | ||
| "packageManager": "pnpm@8.0.0" | ||
| "packageManager": "pnpm@9.15.0" |
There was a problem hiding this comment.
generally this shouldn't be done as part of a PR, but it's a lib so I'm fine with it. Why 9 and not 10?
There was a problem hiding this comment.
I just put the one which is installed on my machine 😅
| /** API endpoint */ | ||
| endpoint: string | null; | ||
| /** HTTP method */ | ||
| method: 'get' | 'GET' | 'post' | 'POST' | 'put' | 'PUT' | 'patch' | 'PATCH' | 'delete' | 'DELETE'; |
There was a problem hiding this comment.
Whilst this is a reasonable goal, I don't think we don't need to strive for fetch parity here. I'd go for one or the other - flexibility is the devil!
| * @returns {Promise<QueryResult>} Response data | ||
| * @throws {HttpError} If the request fails | ||
| */ | ||
| async #doQuery(attempt, client, endpoint, options) { |
There was a problem hiding this comment.
What's with this # syntax? For internal methods I'm more used to seeing _
There was a problem hiding this comment.
# is the official private method https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_properties
| "test": "mocha './!(node_modules)/**/**.+(spec).js'", | ||
| "lint": "eslint lib --ext .js" | ||
| "lint": "eslint lib --ext .js", | ||
| "compile": "tsup" |
There was a problem hiding this comment.
Not sure compile is the right word here. I'd suggest build instead
- Introduced a new ESLint configuration file that extends recommended and mocha rules, setting ECMAScript version to 2025 and source type to module. - Created a pnpm workspace configuration to specify only built dependencies, including 'unrs-resolver'.
commit: |
| run: pnpm build | ||
|
|
||
| - name: Release | ||
| run: pnpm dlx pkg-pr-new publish No newline at end of file |
There was a problem hiding this comment.
we have a workflow for this already, it's better that we use it.
There was a problem hiding this comment.
I found this: https://github.com/beyonk-group/workflows/blob/main/.github/workflows/canary-libs.yml
Any examples I can check on how to integrate this? Or is it copy-pasta? 😁
There was a problem hiding this comment.
There was a problem hiding this comment.
Started using this, now the Action doesn't run 🤔
There was a problem hiding this comment.
Ah IG its because workflows is a private repo while this one is public
antony
left a comment
There was a problem hiding this comment.
Left a link to show you how to use the shared workflows
|
All looks good, but it occurred to me that as you say - a public repo can't use a private workflow! Might have to revert to the existing pkg.pr.new build file for this, sorry! :/ |
A few things about this PR:
Why build step?
I wanna start this sentence with: We do not need a build step. The files are in .js, and will work in runtime. If you import a .js file exposed from a package, into a .js file in a (say sveltekit) app, the typescript will work well there.
The build step however, is there for two possible future cases:
So, we actually do not need the build step in the present at all, but if in any of the above cases, a build step generating .d.ts files is must.
Why We Migrated From Mixin Composition to Direct Class Implementation
Our HTTP API client previously used the mixin composition pattern, which created several challenges when integrating TypeScript types.
The Problem
The previous approach:
compose(MixinA, MixinB, ...)(BaseClass))TypeScript struggled with this pattern because:
thistyping became complex across multiple inheritance layersThe Solution
I consolidated everything into a direct class implementation:
This approach works much better with TypeScript because:
The runtime behavior remains identical, but we get better developer experience, easier maintenance, and reliable bundling.