-
Notifications
You must be signed in to change notification settings - Fork 282
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
Thoughts on converting this project to Typescript? #1106
Comments
@aldy505 We can slowly migrate to TS may be on a different branch . So once we have all the tests passing and validate it, we can create a pull request to the master branch. |
thought on rewriting internal async mechanism to promise and async iterator too? I think it fit better for typescript code would look like this, (this is a example to not change widely used listBuckets(cb?: ResultCallback<BucketItemFromList[]>): void | Promise<BucketItemFromList[]> {
let method = 'GET'
return asCallbackFn(cb, async () => {
const response = await this.makeRequestPromise({ method }, '', [200], DEFAULT_REGION)
const body = await readAll(response)
return xmlParsers.parseListBucket(body.toString())
})
} node runtime only support Also sugesst to remove callback and provide promise style api only as breaking change in v8. promise will support callback well as |
yes, I'd love that.
to be honest, I hate breaking changes. so, I suppose we'll have to keep the callback for a while, at least until the next major version changes. for now, I believe that it's best to progressively migrate parts of typescript, rather than purposely rewrite and make everything better with lots of breaking change like what node-redis library did a year (or two? maybe?) ago. perhaps @prakashsvmx might have a word about this? then again, I'm a person who always believe on the community, if most people are okay of breaking changes for utilizing new node features, then it's fine by me. |
We could always improve progressively without breaking changes. Because any refactoring would lead to more involved effort. |
I have a question, where is the implement of deprecated I can see there are test cases for it but I can't find it's implement minio-js/src/test/unit/test.js Lines 952 to 959 in b74894e
are these tests should be removed? or the |
🤔I have done the migration, just wait PR to be reviewed and merged |
a promise async/await version of original Line 1076 in 119b8c2
|
Because #1120 is taking too long to be merged, I have a question for @prakashsvmx: who maintains the {
"name": "minio",
// ...
"main": "./dist/main/minio.js",
"types": "./index.d.ts", // <-- THIS
// ...
} So we can solve issues like #1097 easily without having to maintain 2 packages at once. It will not cause breaking change either. We can eventually deprecate the |
anyone can send a PR https://github.com/DefinitelyTyped/DefinitelyTyped/commits/master/types/minio |
by the way can maintainers take time to review my PR #1120 ? 👀 it doesn't change any code, only formatting |
I know anyone can send a PR, but because MinIO itself is a company, I suppose that there is someone who usually looks after it.
Sent from Proton Mail for iOS
…On Mon, Apr 24, 2023 at 08:46, Trim21 ***@***.***> wrote:
> who maintains the @types/minio package?
anyone can send a PR https://github.com/DefinitelyTyped/DefinitelyTyped/commits/master/types/minio
—
Reply to this email directly, [view it on GitHub](#1106 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABXP6VQSMRXBUZIMDCEUCADXCXLN7ANCNFSM6AAAAAAV36MHSU).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
No there isn't... |
So sad.
Sent from Proton Mail for iOS
…On Mon, Apr 24, 2023 at 08:58, Trim21 ***@***.***> wrote:
No there isn't...
—
Reply to this email directly, [view it on GitHub](#1106 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABXP6VXSYDP4T6CQFLCQCLLXCXM4FANCNFSM6AAAAAAV36MHSU).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
I've seen #1097, #567 and #611.
The problem with maintaining 2 package:
minio
and@types/minio
that exists on a different repository with different published version is that you won't get 100% correct typing, just because a version mismatch. You can benefit from having to hold the Typescript declaration file without going to@types/minio
using thetypes
field onpackage.json
, or we can generating the typings for Typescript by converting this project to Typescript.The benefit of converting this to Typescript is of course:
If there are any blockers or required discussion, or even there are no plan to convert it yet the members of Minio accept the idea of converting this project to Typescript by community contribution (without ghosting/ignoring the contribution), please let us know.
The text was updated successfully, but these errors were encountered: