Closed 0xdevalias closed 9 months ago
This doesn't look relevant to Preact? If I'm understanding correctly, that is something that needs to be configured in build tooling, not in libraries used.
This doesn't look relevant to Preact? If I'm understanding correctly, that is something that needs to be configured in build tooling, not in libraries used.
@rschristian My understanding was that when the framework (in this case Preact), distributes itself as a minimised bundle, this is something that should be enabled/used/included within it's sourcemaps.
I believe that would then flow on to 'downstream' web app code as well (though don't quote me on that).
With this setting enabled, DevTools hides any file or folder that a framework or build tool has marked as to ignore.
https://developer.chrome.com/blog/devtools-modern-web-debugging/#just-my-code
This doesn't appear to be targetting libraries, no. This is something downstream users should be in control of.
Edit: As such, going to close this on out.
that a framework or build tool has marked as to ignore
@rschristian Do you not consider preact a framework?
It's not, no.
Nuxt, Next, Sveltekit, etc. are frameworks, Preact, Vue, React, Svelte, etc., are UI libraries.
And Angular? Framework or 'UI library'? As they added support:
I've generally seen React/etc referred to colloquially as a framework as well; so I wouldn't be so quick to dismiss the relevance on semantic differences.
It looks like preact
uses microbundle
, which uses rollup
, which supports x_google_ignoreList
:
The zero-configuration bundler for tiny modules, powered by Rollup
I'm not deeply familiar with microbundle
and whether it allows passing through flags to rollup
, or if it's something that would need to be enabled as part of their defaults.
And Angular? Framework or 'UI library'? As they added support:
Take a look at where they added that change, it's in the Webpack config.
Angular is a framework as they have very specific underlying tooling -- you have to write Angular apps with Angular CLI (a Webpack-based tool, though I think that's changing?). This ties Angular to its framework rather tightly, compared to (say) React & Next, Vue and Nuxt, Svelte and SvelteKit, etc.
I've generally seen React/etc referred to colloquially as a framework as well; so I wouldn't be so quick to dismiss the relevance on semantic differences.
I'm not dismissing this due to semantic differences but due to actual intention. This is meant to be implemented in another layer of your tooling, a layer which UI libraries do not control.
I'm not deeply familiar with microbundle and whether it allows passing through flags to rollup, or if it's something that would need to be enabled as part of their defaults.
We maintain Microbundle.
I'm not dismissing this due to semantic differences but due to actual intention.
Fair enough.
This is meant to be implemented in another layer of your tooling, a layer which UI libraries do not control.
I'm still not sure that that is correct. At the layer of preact, I believe it should mark itself to be ignored, so that shows in it's sourcemaps, so that then flows on to the sourcemaps of downstream projects that consume it's sourcemaps.
I may be wrong; and it seems that even if i'm not I'm unlikely to convince you otherwise, so I'll drop the point.
We maintain Microbundle
Fair enough. Well you may or may not find this issue relevant there then, since it's a bundler (though I'm not really sure how a thing like this that should be configurable would be exposed through a 'no config' tool):
At the layer of preact, I believe it should mark itself to be ignored, so that shows in it's sourcemaps, so that then flows on to the sourcemaps of downstream projects that consume it's sourcemaps.
Again, your Angular link is a great example here in usage:
for (const [index, path] of map.sources.entries()) {
if (path.includes('/node_modules/') || path.startsWith('webpack/')) {
ignoreList.push(index);
}
}
As shown, this is happening in a Webpack plugin, during the user's app build. This isn't something that needs to flow on downstream, the consumer/framework can handle this perfectly well on their own.
Now, a good point of implementation could be create-preact
, though it looks like Vite (which create-preact
uses) might already implement this?
Now, a good point of implementation could be create-preact, though it looks like Vite (which create-preact uses) might already implement this?
This is the relevant link on the vite docs, but that's seemingly for the dev server:
server.sourcemapIgnoreList
is the equivalent ofbuild.rollupOptions.output.sourcemapIgnoreList
for the dev server.
By default, it excludes all paths containing node_modules. You can pass false to disable this behavior, or, for full control, a function that takes the source path and sourcemap path and returns whether to ignore the source path.
Note:
server.sourcemapIgnoreList
andbuild.rollupOptions.output.sourcemapIgnoreList
need to be set independently.server.sourcemapIgnoreList
is a server only config and doesn't get its default value from the defined rollup options.
Looking at vite's rollup.config.ts
, both envConfig
and clientConfig
seem to set sourcemapIgnoreList
to true
:
Looking at rollup
's docs for output.sourcemapIgnoreList
, it seems this is a predicate for what to add to the ignore list, and can either be a boolean (that presumably globally enables/disables it), or a function returning a boolean:
So from that, it would seem that create-preact
should already benefit from it, via the default specified in vite
(which is the same sort of default that I thought/still think would make sense to set in microbundle
; but at this stage I'm just accepting that I am potentially wrong and don't know what i'm talking about)
How about a case where the end-app isn't bundled/transpiled/etc, and thus has no chance to mark x_google_ignoreList
for it's own dependencies; but is loading preact
from a CDN. In that case, if preact
directly set x_google_ignoreList
in it's own sourcemap files, it would be correctly ignored listed; but since it doesn't, the end app can't benefit from that. Right?
And if that is true, then based on the above exploration, it seems that the solution for implementing the fix here would just be to set the output.sourcemapIgnoreList
in the rollup config that is building the main preact
outputs (via microbundle
).
And then if that holds true, it also seems that it would probably similarly hold for many/most/all(?) libraries that use microbundle
(that could be imported from a CDN/etc directly, and don't go through a transpilation/bundling step) as well?
It kind of feels like a case of "yes, implementing it at the bundler level is a nice 'catch-many' situation that avoids end libraries from having to do anything"; but I don't believe that negates it being a useful thing for an end library to implement directly? Again, could be wrong, and ultimately the decision is up to you and not something I'm going to push for/get upset if it's not done. Just trying to establish/understand/confirm if the assumptions that decision is based on are actually correct.
How about a case where the end-app isn't bundled/transpiled/etc, and thus has no chance to mark
x_google_ignoreList
for it's own dependencies; but is loadingpreact
from a CDN. In that case, ifpreact
directly setx_google_ignoreList
in it's own sourcemap files, it would be correctly ignored listed; but since it doesn't, the end app can't benefit from that. Right?
Rather than just throwing this out there as a question, I decided to test it. Creating a tiny test file that loads preact
from https://unpkg.com/preact@latest/dist/preact.min.js
:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Preact App</title>
<script src="https://unpkg.com/preact@latest/dist/preact.min.js"></script>
</head>
<body>
<div id="app"></div>
<script>
const { h, render, Component } = preact;
class App extends Component {
render() {
return h('h1', null, 'Hello from Preact!');
}
}
render(h(App), document.getElementById('app'));
</script>
</body>
</html>
Looking at the 'Sources' tab, under 'Authored' -> 'unpkg.com', we can see that preact@latest/src
is still shown, even when "Hide ignore-listed sources" is ticked:
Now if I edit that source to add a debugger
statement in the render:
class App extends Component {
render() {
+ debugger;
return h('h1', null, 'Hello from Preact!');
}
}
// ..snip..
We see that the full call stack is shown in the debugger, including all of the preact
internals that aren't really relevant to my end-user app code:
Now I can work around this by manually configuring the ignore list in my Chrome DevTools and adding a rule such as this:
^https://unpkg\.com/preact@latest/src/
Which will 'dim' the preact@latest/src
entry on the Sources tab when "Hide ignore-listed sources" is disabled:
And it won't show at all when "Hide ignore-listed sources" is ticked:
Now, repeating the debugger
test from above with my manually added ignore rule, we can see that there is a new unchecked "show ignore-listed frames" checkbox, and all of the preact
internals are no longer shown by default in the debugger call stack:
And then if I want to see the preact
internals in this call stack for whatever reason, I can tick the "show ignore-listed frames" checkbox, and they will be visible to me (but dimmed to show that they're generally ignored):
Now while every developer who uses preact
could go and manually configure those ignore rules in their individual DevTools each and every time, that's a lot of cumulative manual effort, which to my understanding, is why the x_google_ignoreList
convention was added to sourcemaps, which allows 'frameworks' (in the general colloquial use of the term), or just 'libraries' in general, to emit this in their library sourcemaps, and have it automagically configured with no manual effort required for any downstream developers. At least, that is my understanding, which has been reinforced by the test I just did above.
Looking at the following page, they also specifically say "framework or library":
If you are a framework or library maintainer, it's essential to understand how to implement these settings to improve your users debugging experience.
What if your favorite framework and build tool doesn’t support it yet? We actively work with frameworks and build tools to land these new settings. You can also help by notifying maintainers about this feature. For example, you can file an issue in their repository.
As I said earlier, if you still choose not to implement this here, that's fair enough; but I don't believe the reasoning you originally based that decision on holds true.
Introduce the
x_google_ignoreList
extension in the sourcemaps generated by this project. This will facilitate a more streamlined debugging experience in Chrome (and other supporting browsers) by automatically filtering out framework and dependency code.Benefit
Implementing
x_google_ignoreList
in the sourcemaps will align this project with modern web development practices, offering a more focused and efficient debugging experience for developers using Chrome DevTools. This change will particularly benefit those who regularly engage in debugging complex applications with numerous dependencies.Background Context
See Also