-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
fix: improve source code location metadata accuracy #8362
Conversation
… preprocessor sourcemap and one based counting
src/compiler/compile/Component.ts
Outdated
if (tracer) { | ||
location = originalPositionFor(tracer, location); | ||
} | ||
location.line += 1; // make line one based |
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.
is this really just zero based vs one based or another cause?
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'm wondering why this all still works the same, since you're always adding +1 to the line, regardless of a source map existing or not.
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.
you're already adding 1 above: https://github.com/sveltejs/svelte/pull/8362/files#r1135771594
so I think this is really adding 2 which seems wrong to me
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.
in a locally linked vite project with sveltekit-ts it produces correct positions in __svelte_meta.
I agree that this looks off and so far havn't been able to understand why it produces the correct result.
@@ -11,14 +11,14 @@ export default { | |||
|
|||
assert.deepEqual(h1.__svelte_meta.loc, { | |||
file: path.relative(process.cwd(), path.resolve(__dirname, 'main.svelte')), | |||
line: 4, | |||
line: 5, |
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.
looking at main.svelte, the h1 sits at line 5, not line 4
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 reverted these changes since it seems like there's some other bug that was present previously. Perhaps something like Rich-Harris/magic-string#248 which was causing some of our other source map tests to assert unexpected behavior
column: 0, | ||
char: 53 | ||
}); | ||
|
||
assert.deepEqual(p.__svelte_meta.loc, { | ||
file: path.relative(process.cwd(), path.resolve(__dirname, 'Foo.svelte')), | ||
line: 1, | ||
line: 2, |
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.
same for the p, the previous combination of line 1, col 1 and char 7 would require cramming 6 chars at col 0.
@dominikg is attempting to deploy a commit to the Svelte Team on Vercel. A member of the Team first needs to authorize it. |
The type error happening in CI is caused by trace-mapping not having a valid "types" reference in package.json and the typescript version svelte uses doesn't understand exports map yet. src/compiler/compile/Component.ts:1:47 - error TS2307: Cannot find module '@jridgewell/trace-mapping' or its corresponding type declarations.
1 import { TraceMap, originalPositionFor } from '@jridgewell/trace-mapping'; given this and the fact that changing line output to be one based could be considered a breaking change i'd suggest to only add this with svelte 4, where we can update typescript and make it a breaking change, even if only relevant for some tooling during dev. |
That's strange, that packages does have type definitions both through top level |
see my PR i sent them, it should be "types" in top level package.json, not "typings" |
Co-authored-by: Ben McCann <[email protected]>
Co-authored-by: Ben McCann <[email protected]>
looks like typescript doesn't ignore missing types with |
Instead of "both", which doesn't make sense at that point.
Co-authored-by: Ben McCann <[email protected]>
- upgrade to TypeScript 5 - upgrade @ampproject/remapping - remove obsolete workarounds --------- Co-authored-by: Simon Holthausen <[email protected]>
bump to rollup 3. Includes reworking the "treat those imports as external" a bit so that Rollup builds correctly but doesn't bundle some of the (now relative) imports --------- Co-authored-by: Simon Holthausen <[email protected]>
I've gotten this down to a single failing test:
I'm not sure why that's failing, but it does seem wrong to me that it's returning a |
This should also properly calculate the character position ( |
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 test failure comes from some sources
not showing up when they should, I think this has to do with how remapping
handles mapping. I'm not sure if this is related to this issue or if we're doing something wrong or if the tests need adjustment.
Edit: After more digging I'm somewhat sure this may be a bug in our implementation. It happens when combining two source maps. The first one is the JS map which points to the original Svelte positions already, the second one is from the Svelte map after preprocessing pointing to the original Svelte positions. Now remapping
traces from the JS map the what's supposed to be original Svelte position to a CSS position because that's what it finds in the Svelte map at that position. So either the JS map needs to skip the preprocess map, or the JS map needs to point to the preprocessed Svelte version.
Edit 2: Ok I think I found the problem - due to this code change, locator
now directly points to the original Svelte version, which is good for the meta thing. But it's bad for the source map combination since that's now unnecessary. So one has to change.
line: 4, | ||
column: 0, | ||
char: 53 | ||
}); | ||
|
||
assert.deepEqual(p.__svelte_meta.loc, { | ||
file: path.relative(process.cwd(), path.resolve(__dirname, 'Foo.svelte')), | ||
// TODO: fix this. the p is on line 2 |
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 think these tests are correct, as source maps are zero line based. There's actually code in Element/index.js
where it substracts one from the returned location to account for that. Why do you think these are incorrect?
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.
source maps are 0-based, but locator
is 1-based because it gets printed out to the user and users would expect it to be 1-based:
svelte/src/compiler/compile/Component.ts
Line 524 in 9aca05b
`${warning.message} (${start.line}:${start.column})\n${frame}` |
I didn't realize that this loc
is different than what's in locator
because I missed the -1
here:
svelte/packages/svelte/src/compiler/compile/render_dom/wrappers/Element/index.js
Line 590 in b8918fa
b`@add_location(${this.var}, ${renderer.file_var}, ${loc.line - 1}, ${loc.column}, ${ |
it's pretty confusing to me to keep track of where things are 0-based and where they're 1-based. I wonder if we can use this opportunity to make it 0-based everywhere and just make it 1-based at the very last second when it's printed to a user
location = originalPositionFor(tracer, location); | ||
// originalPositionFor returns 0-based lines? | ||
// https://github.com/jridgewell/trace-mapping/issues/27 | ||
location.line += 1; |
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.
judging from some other code in language tools and the fact that tracemapping
says it is a drop-in replacement for source-map
which has line-1-based return values, this should not be done
We need to use a different method for getting the meta info because `locate` is used to help construct the source map that references the preprocessed Svelte file. If we would now add source maps to that `locate` function it would go the the original source directly which means skipping potentially intermediate source maps which we would need in other situations. fixes #8360 closes #8362
We need to use a different method for getting the meta info because `locate` is used to help construct the source map that references the preprocessed Svelte file. If we would now add source maps to that `locate` function it would go the the original source directly which means skipping potentially intermediate source maps which we would need in other situations. Sadly we can't map the character offset because for that we would need to the original source contents which we don't have in this context. fixes #8360 closes #8362
by accounting for preprocessor sourcemap and one based counting
fixes #8360
Before submitting the PR, please make sure you do the following
feat:
,fix:
,chore:
, ordocs:
.Tests
npm test
and lint the project withnpm run lint