Strip hygiene code in favor of UUIDs #83
Conversation
| @@ -94,7 +98,7 @@ describe(`process`, function () { | |||
| let output = p.process(`<template>Hi</template>`, { inline_source_map: true }); | |||
|
|
|||
| expect(output).to.match( | |||
| /sourceMappingURL=data:application\/json;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIjxhbm9uPiJdLCJzb3VyY2VzQ29udGVudCI6WyI8dGVtcGxhdGU-SGk8L3RlbXBsYXRlPiJdLCJuYW1lcyI6W10sIm1hcHBpbmdzIjoiO0FBQUEsZUFBQSxTQUFVLENBQUEsRUFBRSxDQUFBLEVBQUE7SUFBQTtRQUFBLE9BQUEsS0FBQSxTQUFBLENBQUEsRUFBVztJQUFEO0FBQUEsR0FBQyJ9/ | |||
| /sourceMappingURL=data:application\/json;base64,/ | |||
There was a problem hiding this comment.
I know nothing about source maps.
and... currently our gjs/gts sourcemaps are very weird in-browser
There was a problem hiding this comment.
It's pretty hard to check the exact source map now that the template imports gets a UUID. This at least confirms that we did get an inline source map of some sort.
There was a problem hiding this comment.
We may need to use magic-string or something (whatever the SWC equiv is) to keep a correct sourcemap. I've just figured out how to get gjs/gts sourcemaps in the browser over here: embroider-build/embroider#2162
There was a problem hiding this comment.
This looks like an empty source map though
There was a problem hiding this comment.
what I missed is that this is just a regex matcher -- it's less precise, but ensures that the sourcemap is present, but doesn't check content
Fixes #71
After conversation with @wycats and reading @chancancode's comments in #71, it seems that our only concern here is making sure that the template import doesn't conflict. If we don't care about potentially importing multiple times (we can't see why we need to), then we can avoid the whole issue by always just importing it with a UUID.