feat: add check on zk parser

[itsacoyote]

What 💻

• Add a console error if a zk tag is unparsed because of bad formatting

Why ✋

• Avoid displaying any unformatted/broken tags in production

Evidence 📷

NOTE

This does not stop a build process from happening. The parser runs on dev and if an error is Thrown it causes all sorts of hiccups on the local server to restart smoothly. For now this is just a console log for the developer to notice. May sit on this and think of a way to throw an error only on build later on.

[github-actions]

Visit the preview URL for this PR (updated for commit a76a332):

https://zksync-docs-staging-5eb09--pr28-itsacoyote-devrl-487-wuthvex2.web.app

_{(expires Tue, 07 May 2024 14:23:22 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: bfaafba5fa82d4f63473aaa76a21fabf1fbb3a11}

[itsacoyote]

Orrrr do we just want to throw a straight up Error and break the server if an unparsed tag is found?

[dutterbutter]

@itsacoyote I think this fine, it will be identified in the CI anyway right? So we will still be aware of the need to fix.

[dutterbutter]

Actually I don't think it would be identified by the CI?

[itsacoyote]

Actually I don't think it would be identified by the CI?

It will not, this is part of the dev process which is why I was worried about throwing an Error in it. While you're developing locally and it throws, it throws a bit of a wrench in the local server and makes it a pain to start back up.

I'll have to look a bit further into the lifecycle of the build process and see if I can find a way to throw only during a build command.

[itsacoyote]

@dutterbutter I've got an error that I can throw and make it fatal but it still doesn't cleanly exit the process with a proper error code. The failure is because the rest of the build process gets borked which isn't really the best way. I'd have to dig into this further but don't want to waste more time on it right now, what are your thoughts on how we should handle this for now?

An error does occur in the Deploy target: staging step but you can see in the action workflow that it looks "successful" and what errors is the link checker. This is because the build gets killed but the error got swallowed up somewhere.

[dutterbutter]

Agreed, let's not spend too much time on this right now. Let's sit on this and think through later, perhaps during offsite. Feel free to keep as is or move to draft state.