Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Pin build-and-lint dependencies

See original GitHub issue

Following up on #13876: the badly-named “build-and-lint” integration test between the JSON API and the TS bindings currently uses unpinned dependencies. That’s a bit of a ticking bomb that is going to explode in our face at some point, as it did last May (when #13876 was made to patch a specific dependency resolution path); the proper fix would be to commit and reuse a specific lockfile for those tests, ensuring that without manual intervention they keep running with the exact same set of dependencies.

Some investigative work is needed to figure out exactly where to find, and where to store, that lockfile.

Initially assigned to @ray-roestenburg-da and @stefanobaghino-da for prioritization.

#15727
- this solves part of this issue at the cost of hiding problems in downstream (i.e. user-run) resolutions. We want to know that the test runs with “latest” broadly
#14873
- this will check that the lockfile is still used, which will otherwise become increasingly untrue as any package.json diverges from the lockfile
update typescript (@types/babel__traverse probably uses too-new syntax for us as of 2022-11-29)
create CI job to remove lockfile and ensure build-and-lint-test passes with lockfile-free resolutions “now”, alert Slack if it fails
- we should treat these failures somewhat like dependabot failures: we don’t want them to break main, but want to be notified out-of-band so that these issues (of temporal nature, exactly like dependabot issues) can be fixed separately
update yarn (we probably can never use --frozen-lockfile even if it works, but our version is pretty old now)