chore: use prettier plugin for jsdoc#513
Conversation
|
New dependencies detected. Learn more about Socket for GitHub ↗︎
|
karfau
left a comment
There was a problem hiding this comment.
I'm not sure where those options should go (assume to the top level?), but I would prefer to enable the tsdoc and jsdocPreferCodeFences options.
|
@shunkica before you invest eny more time into this, I just had a closer look at the plugin from a dependency perspective, and there are some things that make me feel uncomfortable:
That's not a "NO", but some things to consider.
Update I misread the dependencies over there, they are correct, it's just quite a heavy outdated tree... so it is just the prettier v3 support I'm worried about |
|
I have not used this plugin before, but since it is only a dev dependency, has over 40000 weekly downloads, and it did what it is supposed to, I have not given it that much thought. |
|
That looks much more reliable and alive, even though there are not as many downloads. |
|
@karfau 👋 I just published the support for v3, and I'm planning to drop v16 before end of the year (since it's reaching EOL on October). |
|
@homer0 I have added Edit: nevermind, I see now in package.json that prettier v3 is requried for v7 |
|
You might have to also bump prettier and eslint versions at the same time to make it work with v7. Or try to make it work with v6 first |
Yes I figured that out. Do you want to use |
|
Let's first make it work with the current prettier version, I can take care of the updates afterwards |
This reverts commit 58acc86.
|
I’ll take a look tonight (I’m GMT-3), but I tested it with the cli, vscode
ext and my e2e suite and didn’t see anything like that.
Most of the issues I had were about the code not changing, since Prettier
made its api async and I wasn’t awaiting stuff.
I’ll let you know how it goes.
…On Sun, Jul 16, 2023 at 11:59 AM shunkica ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In lib/dom-parser.js
<#513 (comment)>:
> + * an
+ * error
+ * that
+ * prevents
+ * further
+ * processing
+ * in
+ * most
+ * implementations.
+ * .
+ * @Property {boolean} [locator=true] Configures
+ * if
+ * the
+ * nodes
+ * created
+ * during
+ * parsing
+ * will
+ * have
+ * a
+ * `lineNumber`
+ * and
+ * a
+ * `columnNumber`
+ *
+ * attribute
+ * describing
+ * their
+ * location
+ * in
+ * the
+ * XML
+ * string.
+ * Default
+ * is
+ * true.
+ * Default
+ * is
+ * `true`
+ * @Property {(string) => string} [normalizeLineEndings] Used
+ * to
+ * replace
+ * line
+ * endings
+ * before
+ * parsing,
+ * defaults
+ * to
+ * `normalizeLineEndings`
+ * @Property {Object} [xmlns] The
+ * XML
+ * namespaces
+ * that
+ * should
+ * be
+ * assumed
+ * when
+ * parsing.
+ * The
+ * default
+ * namespace
+ * can
+ * be
+ * provided
+ * by
+ * the
+ * key
+ * that
+ * is
+ * the
+ * empty
+ * string.
+ * When
+ * the
+ * `mimeType`
+ * for
+ * HTML,
+ * XHTML
+ * or
+ * SVG
+ * are
+ * passed
+ * to
+ * `parseFromString`,
+ * the
+ * default
+ * namespace
+ * that
+ * will
+ * be
+ * used,
+ * will
+ * be
+ * overridden
+ * according
+ * to
+ * the
+ * specification.
+ * @see NormalizeLineEndings.
*/
@homer0 <https://github.com/homer0> any idea what happened here?
—
Reply to this email directly, view it on GitHub
<#513 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABVATPRMXJ7FFLUSJUXN6ALXQP6TRANCNFSM6AAAAAA2LGHO4U>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Thanks, please note though that this happened with version |
|
Thx a lot, if adding the default value this way is not reliable we have to do it differently. |
|
There is also some kind of conflict between eslint and prettier now, because they produce different versions of the jsdoc. After running prettier format, eslint complains about a bunch of stuff (spaces and such) |
|
Since it is the eslint prettier/prettier rule that is complaining, I will take care of it by separating eslint and prettier. |
|
It turns out the column option was the one causing a bit of a hiccup. I've decided to turn it off for now, as it wasn't really meshing with the overall aesthetic. Hope that's alright! |
karfau
left a comment
There was a problem hiding this comment.
I didn't went through all of the changes, sicne there are already quite some comments/questions.
Feel free to ignore the "content corrections" if you think they are in the way of getting the formatting right, we can also apply them later.
Thx for investing the time, I hope we can find a way to resolve all the open questions and can come up with a config that provides consistency without getting in our way.
This reverts commit 3422cf2.
Co-authored-by: Christian Bewernitz <[email protected]>
|
@karfau is there a reason yml files are used for config? Would you mind a switch to json? ( for prettier and eslint) |
I'm not aware of any specific reason other than it being the default documented format? |
Its one of the documented formats. I wouldn't say it is default. |
karfau
left a comment
There was a problem hiding this comment.
@shunkica I'm fine with the current state.
I configured the jsdocPrintWidth to 95, which is of course an arbitrary number, but I tried different values and this one looked best for the existing content as far as I could judge it.
(I did invest some time into formatting before this new mechanism, so even if it was not totally consistent it was also not without a any consideration.)
Adn I think I would prefer changing the config format in the next PR if you don't mind.
Let me know if there is anything you want ot add to this PR.
I stopped working yesterday because the IDE was was hammering my cpu to 250% yesterday and became unusable. I suspected the culprit was eslint/prettier but couldn't be bothered to investigate further at the time. |
If you are using vscode: whenever you change Prettier/ESLint configs, or install/update dependencies, do a "reload window"; Linting tooling usually becomes buggy because it already had stuff in memory. And just in case, no idea if you are doing it but, don't try to run eslint --fix with Prettier. ESLint is REALLY slow compared to Prettier, added to how fast you can be coding… it creates some fun race conditions :P. |
I am actually using WebStorm, but I didn't have time to figure out what was going on. |
|
@shunkica let me know if you are still observing this slowness after a fresh computer/IDE start. If yes, I will wait for you to figure out what is going on. From the npm scripts we don't do eslint --fix, but I guess it is possible to invoke it from the IDE. I think it is time to apply prettier to staged files in a pre-commit hook asap, to avoid running into formatting issues in the github actions. But this should be a separate PR. Thx a lot @homer0 for all the support and for building and maintaining the plugin. |
|
I can not reproduce the problems I had yesterday. |


This PR includes a commit that adds the prettier-plugin-jsdoc dependency to the project.
The plugin will improve the readability and maintainability of our JSDoc comments and ensure a consistent style across the project.