Developer Docs - apparent incongruence between existing codebase formatting and results of documented lint operations? about obsidian-html HOT 5 OPEN

I became lazy and stopped doing the upkeep because I was the only one working on it 😞

I'll integrate these steps better with my vscode setup so I don't have to remember to do it, it just does it 👍

What do you mean with stripping headers?

Note that I am currently working on building out the module system so that we can write mods that hit the actual note->md conversion stage. This has already required some rewrites in how the modules work. As this is work in progress and probably very buggy and surely not at all documented except for what is in the code comments, all this code is still only on my personal fork: https://github.com/dwrolvink/obsidian-html

So if you are going to do a lot of work I'd suggest we both stay in our own forks for a while and stick our heads together when we are both ready to commit to master :)

from obsidian-html.

What do you mean with stripping headers?

Oh sorry. I was referencing this reply in #766. The private feature that interferes with the inclusion-highlighting and that kicked off our small discussion over there.

I'd suggest we both stay in our own forks

Sure thing. I would have recommended the same. As per the nature of why I do commits right now (thesis reproducibility requirements) I can link to the basic solution I wrote once I push them to GH on this user. I will probably do a branch per mod, then just make a private pseudo-master to merge all of them to so I don't start screaming for separation-issues once/if we go ahead on those.

I'll integrate these steps better with my vscode setup so I don't have to remember to do it, it just does it 👍

I'd be interested how you're doing so if you care/are able to explain - for similar reasons. Linting is not something I just remember to do unfortunately.

from obsidian-html.

This has already required some rewrites in how the modules work. As this is work in progress and probably very buggy and surely not at all documented except for what is in the code comments [...]

Which is why I am currently refraining from modularising the various modifications I am using. They are either baked in, or simple function calls.

from obsidian-html.

I've resorted to setting this now:

• https://github.com/dwrolvink/obsidian-html/blob/master/docs/developer_docs.md#linting-automation

Some issues though:

• Files that aren't committed yet are also checked, which can potentially be very annoying
• I can't easily disable the pre-commit script, as setting an env var (for example) in my terminal is not picked up by vscode. So this means I just disable the check in code, and there is nothing to then remind me in the future 🥴

I'm thinking of adding a step to the merge pipeline that does checking at that stage, which might be nicer, as it may trigger me to do the formatting then

from obsidian-html.

Maybe I am missing something right now, but what hinders you from just using a pre-commit hook to force rendering?

Additional files would be linted the first few times, but once the project is fully linted once, only new changes should become subject to change for the linter.

Or am I misunderstanding something right now?

from obsidian-html.