Encode ampersands in markdown code blocks

[tony-sull]

Closes #3487

Changes

Updates rehype to encode ampersands in code blocks

Testing

Added tests for markdown <code> and fenced code blocks

Docs

N/A

[changeset-bot]

🦋 Changeset detected

Latest commit: afaab05

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@astrojs/markdown-remark	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[FredKSchott]

LGTM! A shame we have to do all of these as one-offs. For a future PR, is there a more generic encoding function or html encoder npm package that we could call on this? No worries if not, just a thought.

[natemoo-re]

LGTM!

[tony-sull]

@FredKSchott I believe @hippotastic is actually working on a larger update that moves more of the work out of our custom markdown plugins - hopefully the days of one-off markdown fixes are coming to an end!

[hippotastic]

Hey, thanks for mentioning that I'm working on something in that area! 😄 Just to clarify a bit - I'm working on two main things right now:

1. A large amount of new test cases which ensure that our Markdown-to-HTML pipeline works as it should, and doesn't crash or produce invalid output. I didn't trust our test coverage so far, so I always ran a build of our Astro Docs site and performed a side-by-side file comparison of the build output between Astro versions to find any issues introduced by Markdown-related code changes. This is how I also found this bug that Tony just fixed. This is of course not something we can expect other contributors to do, and our tests should cover that.
2. A preprocessor that is able to transform documents that are valid Markdown as per the CommonMark/GFM spec to valid MDX documents that (A) do not crash the parser because of trivial formatting mistakes and (B) produce HTML output that comes as close as possible to the Markdown author's recognizable intention. This is important to make migration to Astro as smooth as possible - if you look at a document and think that it looks valid, it should just work and not fail the build due to a seemingly unclosed nested paragraph.