-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework Vite and Astro logger for HMR messages #9139
Conversation
🦋 Changeset detectedLatest commit: 14012c3 The changes in this PR will be included in the next version bump. 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is blocked because it contains a minor
changeset. A reviewer will merge this at the next release if approved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all looks quite reasonable!
const isSkipLog = | ||
/astro\.config\.[cm][jt]s$/.test(filename) || | ||
/(\/|\\)\.astro(\/|\\)/.test(filename) || | ||
isPkgFile(filename); | ||
if (!isSkipLog && dedupeHotUpdateLogs(filename)) { | ||
logger.info('watch', filename.replace(config.root.pathname, '/')); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part can be removed as Vite now logs the actual changed files instead. The dedupe should also not be needed now as we log things through the Vite logger.
const stripped = stripAnsi(msg); | ||
let m; | ||
// Rewrite HMR page reload message | ||
if ((m = vitePageReloadMsg.exec(stripped))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fact that some files are logged by Vite with a leading /
and some are not is pretty odd and would confuse me as a user (especially on windows where I imagine one would have /
and the other would have \
). Does Vite consider this a bug?
I also don't love matching strings like this with regex, since these error messages aren't usually covered by semver and can change unexpectedly across different versions.
I think I prefer the solution that keeps handling this ourselves in handleHotUpdate
where we can control things ourselves, for those reasons. But I also could be missing some benefits!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left a note in the description about the slash issue:
NOTE: there's a leading slash inconcistency for [watch] messages, seems to be intended in Vite. Leading slash is the URL, non-leading slash is for local files.
I investigated that yesterday and it seems safer this way since you may sometime get /@fs/some/fs/path
and it would not be safe to remove the initial slash.
If we put back in handleHotUpdate
, we won't be able to fix #8224 though. Since an update that calls handleHotUpdate
doesn't always trigger HMR, e.g. if you're editing files that are not part of your app.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also didn't find a cleaner way besides the regex, though Vite hasn't changed those HMR messages across many majors now. It seems to be the easiest way to get the exact paths that would trigger HMR + whether the HMR will trigger a page reload or HMR update, which our logs don't differentiate now but we could.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I won't block this via GitHub, but I'm worried this is a step backwards on some of the improvements of #9105 and #9129.
I left some comments on the two specific spots! If there's a way that you can refactor & fix the original bug without impacting the logging behavior at all, then I'm +1 on merging!
I can also make time early tomorrow morning my time to talk through this, if it would helpful to not block you. LMK!
@bluwy can you share some examples of errors that are logged, but not thrown as errors? My theory is that all Vite errors are also thrown, so the Vite error log is unnecessary. If that's not true and you can share some situations where that's not true, I'll feel better about moving from |
Based on the new rebased branch I'm no longer -1. I'm still very nervous about so much string matching and the potential for those to drift in patch/minor releases, but I can stomach it if there's no better alternative. It would be nice if this could encourage an effort to code errors and/or logs in Vite, so that this would be less flakey without needing to rely on string matching. |
The full list can be found with a One example you can try is something like http://localhost:4321/@fs/Users/bjorn/.gitconfig (or similar) where you're accessing URLs outside your project:
Another example is with a Vite reports a better error than the default one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for digging into the feedback @bluwy, I feel much better now (maybe even excited?) about the new approach, and the fact that we can always tweak this post 4.0 on a per-error basis.
Changes
fix #8224
This PR removes the Vite
logLevel: 'warn'
default (nowinfo
instead), and reuse Vite's logger so we get properly HMR messages for files that actually changed.This also refactors the logging flow as a follow-up from #9105
Examples
framework-vue
(dev). Updated filessrc/components/Counter.vue
,src/pages/index.astro
,astro.config.mjs
, and thenpackage.json
, which triggered these logs:Open screenshot
framework-vue
(build):Open screenshot
core-image-errors
fixture, error is only logged once:Open screenshot
Notes
This change helps unblock using Vite's
bindCLIShortcut
utility for us to implement CLI shortcuts easily. I think it's good that plugins can log infos by default too, e.g. vite-plugin-qrcode doesn't log anything today because we blockinfo
messages.Testing
Tested the logging manually. And ran the tests locally.
Docs
The logging changes shouldn't need to be documented.