Investigate running integration test code against the compiled extension

[ryanluker]

Description

370 Exposes an issue with how our unit and integration test works compared to the compiled extension code.

AC

• [ ] Investigate using the compiled extension code for integration tests
• [ ] Investigate smoke tests for the compiled vsix
• [ ] Investigate other ways to have caught this issue before release

[mattseddon]

@ryanluker what was the issue? Why was the build expecting tslib when it wasn't present?

Edit: I did some reading and it seems like you would only need to manually build + install and test the extension when making changes to the tsconfig... this also seems like an edge case as I've never seen the need to install external libs which are not required directly by the code as runtime dependencies before.

[ryanluker]

@mattseddon No clue on the origin of the issue yet, and I agree that it might be overkill to manually build and install to test, definitely. I was just annoyed that we put out a release that caused regressions for folks when the test suite passing 😅.

The only thing that came to mind was the external extension dependency we have now, but I don't think that would cause us to need the tslib in the runtime deps...

https://github.com/ryanluker/vscode-coverage-gutters/commit/f58addc4b2298b75f3e47d3bac9c1a5378752896

[mattseddon]

The change is when you added importHelpers: true to your tsconfig: https://www.typescriptlang.org/tsconfig#importHelpers

Some code change must've caused a different transpilation and then... you hit the code path where tslib should have been.

[ryanluker]

@mattseddon Very interesting, it occurred when I was upgrading node to 16 and I applied some more typescript strictness 🤔. https://github.com/ryanluker/vscode-coverage-gutters/commit/4a5877688df2fff7ba31f580dd4a0e1f41ac6841