Repository navigation
Conversation
Part of an internal project at Google, but likely useful more broadly. Similar to the existing source locations op, but this is template system agnostic and includes more precise ranges suitable for bidirectionally mapping between source code and HTML. Doc with more internal info: go/html-source-loc.
| env.driveMain(); | ||
| const content = env.getContents('test.js'); | ||
| expect(content).toContain('ɵɵdomElementStart(0, "div")(1, "span")(2, "strong");'); | ||
| expect(content).toContain('ɵɵdomElementStart(0, "div", 0)(1, "span", 1)(2, "strong", 2);'); |
There was a problem hiding this comment.
Why did these additional arguments show up?
There was a problem hiding this comment.
I believe it's because there are additional attributes on the elements now, because of the new data-sourcecode-loc attributes being added when the flag that controls this feature is enabled
| import * as ir from '../../ir'; | ||
| import type {ComponentCompilationJob} from '../compilation'; | ||
|
|
||
| /** |
There was a problem hiding this comment.
Couldn't we reuse the existing attachSourceLocations here? As far as I can tell the main differences here are:
- We attach more information here (e.g. both start and end positions).
- We can call the attribute something different.
- The formatting is different.
We only have one user of this internally so we can work with them to account for any changes we make to the formatting.
There was a problem hiding this comment.
Oh cool, I wasn't sure that there weren't more users. I'm coordinating with that user for them to suppor data-sourcecode-loc. Follow along at https://b.corp.google.com/510157286
|
We ended up handling this through #70303. |
|
This pull request has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Part of an internal project at Google, but likely useful more broadly. Similar to the existing source locations op, but this is template system agnostic and includes more precise ranges suitable for bidirectionally mapping between source code and HTML.
Doc with more internal info: go/html-source-loc.
I'm piggybacking off of job.enableDebugLocations but happy to create a new flag for this purpose instead.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the new behavior?
This adds a new kind of opt-in debug metadata.
Does this PR introduce a breaking change?