-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Move types from @types/parse to this repository. #7336
Move types from @types/parse to this repository. #7336
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7336 +/- ##
==========================================
- Coverage 93.91% 93.89% -0.02%
==========================================
Files 181 181
Lines 13194 13194
==========================================
- Hits 12391 12389 -2
- Misses 803 805 +2
Continue to review full report at Codecov.
|
Are you sure the effort you put into this PR is worth it? Whether types are in DefinitelyTyped or in this repo won't make any difference to the developer. This PR will be "reverted" with generated types, for which there is even an already working PR #7335. Would it make more sense to start a PR with See #7334 (comment) |
It took me less than 10 minutes, and splitting types between repo is maybe another 20-30 minutes :)
Yep, see #7337, but as i fear, there is > 1000 Typescript errors ;) |
As discussed in #7335, I feel like it makes sense for these to be in the JS SDK repo, as the types are mostly related to JS methods such as I think the types here should be related to ParseServer (such as enforcing databaseURI is a string), which I believe currently happens here. |
Yes, it will be, i'm just waiting for your OK on this "proof of concept" and ill submit also a PR in |
I still don't understand what the purpose of moving the manual types into our repos is, what benefit does that bring? And again, this exercise will be reverted in a few weeks, maybe even before the next release, by auto generated types. A benefit of keeping manual types in DefinitelyTyped while gradually building our automated types may be that developers can choose either one and switch to auto types onces they are mature enough. Any effort put into the manual types will be for nothing. @dblythy manually updated the types to do some quick fixes for developers who already use the types, I get that. But now we want to put even more effort into manual types, although they will be gone soon? |
The only point of moving the types over is to make them more maintnable and up to date. If you think it's a mather of weeks for getting generated types working , I'll just close the issue/PR, and we will go for the generated Avenue for sure! For what I've seen so far, getting generated types to work was quite.a big undertaking. While just bringing the types back in their appropriate repos is like a 1 hour job ... |
New Pull Request Checklist
Issue Description
Related issue: #7334
Approach
This is the step (1) discussed in #7334. Simply move the declarations from
@types/parse
to here.WIP If it seems OK, ill split up the types definitions and submit a PR in the
js-sdk
so each projects have their respective typesI'll also make another PR later with tests from
flow-to-typescript
in order to generate types definitions directly from the code. ( again discussed previously in #7334 )TODOs before merging
Split definitions in
js-sdk
andserver
Add entry to changelog