fix(sourcemaps): do not encode inline sourcemaps

[rwaskiewicz]

Pull request checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
• Build (npm run build) was run locally and any changes were pushed
• Unit tests (npm test) were run locally and passed
• E2E Tests (npm run test.karma.prod) were run locally and passed
• Prettier (npm run prettier) was run locally and passed

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

this commit fixes a regression originally introduced in #3100, where
inline sourcemaps that are data URI's are erroneously encoded using
RFC-3986. this causes the sourcemaps for tests to not correctly map the
transpiled output back to the original source code.

GitHub Issue Number: #3147

What is the new behavior?

do not URI encode the data prefix+mime type

Does this introduce a breaking change?

• Yes
• No

Testing

To test, I spun up 2 component libraries using npm init stencil:

1. with-sourcemap-issue, which is the standard output one would see from the Stencil CLI (with v2.11.0 installed)
2. with-local-stencil-build, which differs from the above only in name and has a Stencil build with this branch installed on it (npm ci && npm run build && npm pack to generated the tarball, then installed with npm i <PATH_TO_TAR>)

From there, I ran through the two test cases described in the issue summary of #3147, described below

'For Call Stacks'

Reproduction setup (in both projects):

1. Open utils.ts and add a throwing code to line 2. Example: '1'.d();

export function format(first: string, middle: string, last: string): string {
+ '1'.d();
  return (first || '') + (middle ? ` ${middle}` : '') + (last ? ` ${last}` : '');
}

2. npm test -- --coverage --verbose --no-cache

Outcomes:
In with-sourcemap-issue, the sourcemap does not map back to the correct line, which should be "(src/utils/utils.ts:2:7)" (where I added the line). In with-local-stencil-build, the sourcemap maps back to the correct line. The results are shown below, where with-sourcemap-issue is on the left, and with-local-stencil-build is on the right

'For Coverage'

Reproduction setup (in both projects):

1. Open utils.ts and add a branching expression that will never be hit

export function format(first: string, middle: string, last: string): string {
+  if (1==2) {
+    first = middle;
+  }
  return (first || '') + (middle ? ` ${middle}` : '') + (last ? ` ${last}` : '');
}

2. npm test -- --coverage --verbose --no-cache

Outcomes:
In with-sourcemap-issue, the sourcemap does not map back to the correct line when opening the coverage report. (the coverage reports can be found in the coverage/ dir in the root of each project). In with-local-stencil-build, the sourcemap maps back to the correct line in the coverage report. The results are shown below, where with-sourcemap-issue is on the left, and with-local-stencil-build is on the right.

Note how the uncovered line number column is incorrect for the following code (which is the same piece of code in each project) on the left, and correct on the right

Other information

Shoutout to @johnjenkins for their work in debugging this! #3147 (comment)

[rwaskiewicz]

Moving this to a draft while I add a few more tests

[rwaskiewicz]

Ready to go! Did a little more testing around weird file names like util+foo.ts and utili().ts to make sure sourcemaps work there as well (since the name of the file is included in the sourcemap, we need to handle that and now do)

[rwaskiewicz]

This fix has been included in the v2.12.0 release.

[PMudra]

Thanks for this fix!

I am not 100% sure about this, but maybe this change also fixed my issues with toMatchInlineSnapshot in my tests. I have been using v2.11.0 and I haven't been able to initialize and update inline snapshots. Upgrading to v2.12.1 fixed that issue.