feat: use logger instead of console where possible

[florian-lefebvre]

Description (required)

Updates API references

References

• Related to feat: use logger instead of console where possible astro#17818

• For Astro version 7.3.0

[astrobot-houston]

Lunaria Status Overview

🌕 This pull request will trigger status changes.

Learn more

By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.

You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

File	Note
en/reference/cache-provider-reference.mdx	Source changed, localizations will be marked as outdated.
en/reference/image-service-reference.mdx	Source changed, localizations will be marked as outdated.

Warnings reference

Icon	Description
🔄️	The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

[github-actions]

Preview deployment

✅ Deployment complete!

• Latest commit: dbe0574
• Preview: https://feat-runtime-logger.previews.docs.astro.build
• Workflow run: View logs

[ArmandPhilippot]

Thanks, Florian! Sorry this is only a partial review for now as I have to go. But, I suspect we want a similar change on the transform() API.

My thinking is that onRequest() and transform() remain the main topic. The logger description is maybe "too visible" and can distract from the main purpose of the section. The goal is not to log, even though this is a nice addition. 😄

[ArmandPhilippot]

Review part 2, see my comment. This is a similar feedback as the one I gave on onRequest(), but as TL/DR: I think it's even trickier than the previous one because of the four distinct parameters.

Not right now, but I’ll try to take the time to think about how we can improve the API references. I think highlighting optional properties is helpful (and this was already on my TODO list)... but maybe we should also have a way to highlight additional arguments. They do not always fit well into the existing description / this requires a more extensive rewrite to include them. 🤔

[florian-lefebvre]

Always happy to find weird cases 😂! I think your suggestions made sense, done them locally

[ArmandPhilippot]

Thanks, LGTM! 🙌🏽

[ArmandPhilippot]

I left a suggestion regarding parseURL() because I think there is an issue with the flow. Otherwise, LGTM!

[ArmandPhilippot]

I could be wrong (not an English expert...) but I think "This" after "It" is confusing? And, maybe this requires a bit of reorganization to make the whole thing flow better? Something bothers me with this one.

Maybe:

Suggested change

	This hook parses the generated URLs by `getURL()` back into an object with the different properties to be used by `transform` (for on-demand rendering and in dev mode). It is unused during build. This receives three parameters: the URL to parse, the image configuration and, since Astro v7.3.0, a logger.
	This hook parses the generated URLs by `getURL()` back into an object with the different properties to be used by `transform`. This receives three parameters: the URL to parse, the image configuration and, since Astro v7.3.0, a logger.
	This hook is used only for on-demand rendering and in development mode. It is unused during build.