-
Notifications
You must be signed in to change notification settings - Fork 44
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
fix missing types and jsDocs #89
Conversation
I enabled strict types and fails cc. @johnhooks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@erikyo looking good, my overall suggestion is to only attempt adding the initial set of types, not fixing logical or type errors. It would be nice to do those one at a time in separate PRs so they can get the attention they deserve.
src/mocompiler.js
Outdated
* @param {import('./types.js').GetTextTranslations['translations']} translations | ||
* @return {import('./types.js').GetTextTranslations['translations']} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you use the suggestion above, I would also declare the Translations
type like this:
// At the top of the file with the other type import. We can use `GetTextTranslations` directly because it's already imported.
/**
* @param {GetTextTranslations['translations']} Translations
*/
* @param {import('./types.js').GetTextTranslations['translations']} translations | |
* @return {import('./types.js').GetTextTranslations['translations']} | |
* @param {Translations} translations | |
* @return {Translations} |
I haven't checked, though if Translations
could be typed separately, rather than looking it up with key access on GetTextTranslations
, that would be preferred. If that is acceptable then it would change to:
// At the top of the file with the other type import. We can use `GetTextTranslations` directly because it's already imported.
/**
* @typedef {import('./types.js').Translations) Translations
*/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes be patient but that is the fastest way with my IDE to generate jsdocs types. a 'cleaner' commit will follow all these changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks to me like you didn't import them. Is it okay for me to PR this branch so you can see what I mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure! I think you have even permission to edit my repo, if not tell me
* @property {number} [foldLength] the fold length. | ||
* @property {boolean} [escapeCharacters] Whether to escape characters. | ||
* @property {boolean} [sort] Whether to sort messages. | ||
* @property {string} [eol] End of line character. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would declare all the types in a types.ts
file, I think that is pretty standard practice when using JSDocs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i would suggest a PR after this one that stabilizes imports and sorting for jsDocs. in this one I would feel satisfied if I can reduce the errors to zero :😇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
however, I do not know if it is a good practice or not to create a '.ts' for declarations, but I think there would be problems with running tests for example, it would force one to use tsnode
to execute the suite
|
||
this._translations = []; | ||
|
||
this._writeFunc = 'writeUInt32LE'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That assignment appears to have been established at some point, presumably intended for modification through options. However, with no implementation efforts undertaken, it remains as unused memory.
https://nodejs.org/api/buffer.html#bufwriteuint32levalue-offset
These serve as the 'placeholders' for the associated function name utilized for reading bytes from the po/mo files. Frankly, I'm uncertain whether it's worthwhile to implement the others, as file writing should adhere to a similar approach.
this made typing more complicated, what do you say I leave it or is it OK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would argue that byte order should be an option of the compiler, so rather than remove the concept of changing the write function we should fix it.
If a mo file is parsed in a specific byte order it should be rewritten in the same order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be an option of the compiler
i think this requires a separate issue. won't fix in this pr
Co-authored-by: John Hooks <[email protected]>
Co-authored-by: John Hooks <[email protected]>
will apply the suggestion asap... thank you John! Anyhow check this: https://github.com/smhg/gettext-parser/pull/89/checks there are only about 30 type errors left 🚀 then we are good to go |
The remaining types I sincerely believe require something structural that cannot be done in this pr. I am referring for example to these which should be classes ( gettext-parser/src/poparser.js Line 590 in babf333
what do you think @johnhooks? should I disable the type checking in order to pass again the tests so then we can focus on the last 20-30 issues? |
@erikyo I think it's fair to set |
in this case we should split the CI actions into 2 different steps because otherwise it will allow the tests to fail |
42498d6
to
981551b
Compare
fixed, and fixed the reporter in the code tab (previously was duplicated) |
This commit adds missing types and attempts fix type errors. There are still a few type errors, though how to fix them is not clear. Adds the `Translations` type for the `translations` property of the `GetTextTranslations` type.
fix: adjust typing of the parsers and compilers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great @erikyo, very exciting to get the type errors resolved and have the declarations output for exporting first party types.
This pull request addresses the need for consistent documentation within the repository by adding JSDoc comments where they were previously missing.
This enhances code readability and maintainability.
Each file has been reviewed and updated as necessary to ensure comprehensive documentation coverage.