chore(deps): Deduplicate yarn.lock

[nwalters512]

I'm splitting this out of #14967 since it was getting a little out of hand in that other PR.

Tests are currently failing, seemingly related to ampproject/remapping#193. It seems like this may only have been fixed in vitest v2? So that might be a blocker for these changes.

There's another strange failure in the packages/browser test:

 FAIL test/eventbuilder.test.ts > extractMessage > should extract message from a WebAssembly.Exception object
AssertionError: expected 'No error message' to be 'wasm exception' // Object.is equality
- Expected
+ Received
- wasm exception
+ No error message
❯ test/eventbuilder.test.ts:188:21
186| 187| const message = extractMessage(wasmException);
188| expect(message).toBe('wasm exception');
| ^
189| });
190| 

However, this also fails for me on the develop branch, so this may not be related to these changes.

[nwalters512]

@mydea I'm unable to reproduce the integration test failures (https://github.com/getsentry/sentry-javascript/actions/runs/12751414906/job/35538905465?pr=14968) locally. I'm frankly not sure why integration tests seem to be performing type checking in the first place. Can you offer any guidance here? Maybe this is related to dependency caching in CI? Thanks!

Edit: I see now that it's testing against TS 3.8, and that I need to run node ./scripts/use-ts-3_8.js locally to reproduce this.

[nwalters512]

It looks like the type errors are occurring because @types/express-serve-static-core uses modern TypeScript features that aren't supported by TypeScript 3.8, e.g.:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/c55a1e4fd5c048683bfd7c55340c78193124d11b/types/express-serve-static-core/index.d.ts#L105

Support for this was only introduced in TypeScript 4.1: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html

This was introduced to those types 4 years ago: DefinitelyTyped/DefinitelyTyped#51262

And as of 2 years ago, TypeScript <=4.0 is no longer supported by DefinitelyTyped: DefinitelyTyped/DefinitelyTyped#62240

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

[nwalters512]

In 30b8213 I updated the TypeScript 3.8 script to use resolutions in package.json to pin the Express types to older versions, which worked for me locally.

[AbhiPrasad]

Marking myself as a reviewer, will take a look ASAP!

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

Because we want to be as a compatible with many users as possible. We said we would support 3.8+ with our 8.x major version, so we need to test to make sure we support it. We often hold support for things much longer than typical LTS for most JS libraries: https://develop.sentry.dev/sdk/philosophy/#compatibility-is-king

[nwalters512]

I'm not sure why things are failing after getting up to date with develop 😢 I'll poke at this tomorrow.

[nwalters512]

Looks like the failing tests were fixed in #15001.

[nwalters512]

If y'all want to check for a maximally-deduped lockfile in CI (I'd strongly advise this), you can add a npx yarn-deduplicate --check step to CI. Let me know if this is desired and I can add it.

Once you're using Yarn v4, this is built in via yarn dedupe/yarn dedupe --check.

[nwalters512]

I'm splitting this out of #14967 since it was getting a little out of hand in that other PR.

Tests are currently failing, seemingly related to ampproject/remapping#193. It seems like this may only have been fixed in vitest v2? So that might be a blocker for these changes.

There's another strange failure in the packages/browser test:

 FAIL test/eventbuilder.test.ts > extractMessage > should extract message from a WebAssembly.Exception object
AssertionError: expected 'No error message' to be 'wasm exception' // Object.is equality
- Expected
+ Received
- wasm exception
+ No error message
❯ test/eventbuilder.test.ts:188:21
186| 187| const message = extractMessage(wasmException);
188| expect(message).toBe('wasm exception');
| ^
189| });
190| 

However, this also fails for me on the develop branch, so this may not be related to these changes.

[nwalters512]

@mydea I'm unable to reproduce the integration test failures (https://github.com/getsentry/sentry-javascript/actions/runs/12751414906/job/35538905465?pr=14968) locally. I'm frankly not sure why integration tests seem to be performing type checking in the first place. Can you offer any guidance here? Maybe this is related to dependency caching in CI? Thanks!

Edit: I see now that it's testing against TS 3.8, and that I need to run node ./scripts/use-ts-3_8.js locally to reproduce this.

[nwalters512]

It looks like the type errors are occurring because @types/express-serve-static-core uses modern TypeScript features that aren't supported by TypeScript 3.8, e.g.:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/c55a1e4fd5c048683bfd7c55340c78193124d11b/types/express-serve-static-core/index.d.ts#L105

Support for this was only introduced in TypeScript 4.1: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html

This was introduced to those types 4 years ago: DefinitelyTyped/DefinitelyTyped#51262

And as of 2 years ago, TypeScript <=4.0 is no longer supported by DefinitelyTyped: DefinitelyTyped/DefinitelyTyped#62240

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

[nwalters512]

In 30b8213 I updated the TypeScript 3.8 script to use resolutions in package.json to pin the Express types to older versions, which worked for me locally.

[AbhiPrasad]

Marking myself as a reviewer, will take a look ASAP!

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

Because we want to be as a compatible with many users as possible. We said we would support 3.8+ with our 8.x major version, so we need to test to make sure we support it. We often hold support for things much longer than typical LTS for most JS libraries: https://develop.sentry.dev/sdk/philosophy/#compatibility-is-king

[nwalters512]

I'm not sure why things are failing after getting up to date with develop 😢 I'll poke at this tomorrow.

[nwalters512]

Looks like the failing tests were fixed in #15001.

[nwalters512]

If y'all want to check for a maximally-deduped lockfile in CI (I'd strongly advise this), you can add a npx yarn-deduplicate --check step to CI. Let me know if this is desired and I can add it.

Once you're using Yarn v4, this is built in via yarn dedupe/yarn dedupe --check.

[nwalters512]

I'm splitting this out of #14967 since it was getting a little out of hand in that other PR.

Tests are currently failing, seemingly related to ampproject/remapping#193. It seems like this may only have been fixed in vitest v2? So that might be a blocker for these changes.

There's another strange failure in the packages/browser test:

 FAIL test/eventbuilder.test.ts > extractMessage > should extract message from a WebAssembly.Exception object
AssertionError: expected 'No error message' to be 'wasm exception' // Object.is equality
- Expected
+ Received
- wasm exception
+ No error message
❯ test/eventbuilder.test.ts:188:21
186| 187| const message = extractMessage(wasmException);
188| expect(message).toBe('wasm exception');
| ^
189| });
190| 

However, this also fails for me on the develop branch, so this may not be related to these changes.

[nwalters512]

@mydea I'm unable to reproduce the integration test failures (https://github.com/getsentry/sentry-javascript/actions/runs/12751414906/job/35538905465?pr=14968) locally. I'm frankly not sure why integration tests seem to be performing type checking in the first place. Can you offer any guidance here? Maybe this is related to dependency caching in CI? Thanks!

Edit: I see now that it's testing against TS 3.8, and that I need to run node ./scripts/use-ts-3_8.js locally to reproduce this.

[nwalters512]

It looks like the type errors are occurring because @types/express-serve-static-core uses modern TypeScript features that aren't supported by TypeScript 3.8, e.g.:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/c55a1e4fd5c048683bfd7c55340c78193124d11b/types/express-serve-static-core/index.d.ts#L105

Support for this was only introduced in TypeScript 4.1: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html

This was introduced to those types 4 years ago: DefinitelyTyped/DefinitelyTyped#51262

And as of 2 years ago, TypeScript <=4.0 is no longer supported by DefinitelyTyped: DefinitelyTyped/DefinitelyTyped#62240

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

[nwalters512]

In 30b8213 I updated the TypeScript 3.8 script to use resolutions in package.json to pin the Express types to older versions, which worked for me locally.

[AbhiPrasad]

Marking myself as a reviewer, will take a look ASAP!

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

Because we want to be as a compatible with many users as possible. We said we would support 3.8+ with our 8.x major version, so we need to test to make sure we support it. We often hold support for things much longer than typical LTS for most JS libraries: https://develop.sentry.dev/sdk/philosophy/#compatibility-is-king

[nwalters512]

I'm not sure why things are failing after getting up to date with develop 😢 I'll poke at this tomorrow.

[nwalters512]

Looks like the failing tests were fixed in #15001.

[nwalters512]

If y'all want to check for a maximally-deduped lockfile in CI (I'd strongly advise this), you can add a npx yarn-deduplicate --check step to CI. Let me know if this is desired and I can add it.

Once you're using Yarn v4, this is built in via yarn dedupe/yarn dedupe --check.

[nwalters512]

I'm splitting this out of #14967 since it was getting a little out of hand in that other PR.

Tests are currently failing, seemingly related to ampproject/remapping#193. It seems like this may only have been fixed in vitest v2? So that might be a blocker for these changes.

There's another strange failure in the packages/browser test:

 FAIL test/eventbuilder.test.ts > extractMessage > should extract message from a WebAssembly.Exception object
AssertionError: expected 'No error message' to be 'wasm exception' // Object.is equality
- Expected
+ Received
- wasm exception
+ No error message
❯ test/eventbuilder.test.ts:188:21
186| 187| const message = extractMessage(wasmException);
188| expect(message).toBe('wasm exception');
| ^
189| });
190| 

However, this also fails for me on the develop branch, so this may not be related to these changes.

[nwalters512]

@mydea I'm unable to reproduce the integration test failures (https://github.com/getsentry/sentry-javascript/actions/runs/12751414906/job/35538905465?pr=14968) locally. I'm frankly not sure why integration tests seem to be performing type checking in the first place. Can you offer any guidance here? Maybe this is related to dependency caching in CI? Thanks!

Edit: I see now that it's testing against TS 3.8, and that I need to run node ./scripts/use-ts-3_8.js locally to reproduce this.

[nwalters512]

It looks like the type errors are occurring because @types/express-serve-static-core uses modern TypeScript features that aren't supported by TypeScript 3.8, e.g.:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/c55a1e4fd5c048683bfd7c55340c78193124d11b/types/express-serve-static-core/index.d.ts#L105

Support for this was only introduced in TypeScript 4.1: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html

This was introduced to those types 4 years ago: DefinitelyTyped/DefinitelyTyped#51262

And as of 2 years ago, TypeScript <=4.0 is no longer supported by DefinitelyTyped: DefinitelyTyped/DefinitelyTyped#62240

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

[nwalters512]

In 30b8213 I updated the TypeScript 3.8 script to use resolutions in package.json to pin the Express types to older versions, which worked for me locally.

[AbhiPrasad]

Marking myself as a reviewer, will take a look ASAP!

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

Because we want to be as a compatible with many users as possible. We said we would support 3.8+ with our 8.x major version, so we need to test to make sure we support it. We often hold support for things much longer than typical LTS for most JS libraries: https://develop.sentry.dev/sdk/philosophy/#compatibility-is-king

[nwalters512]

I'm not sure why things are failing after getting up to date with develop 😢 I'll poke at this tomorrow.

[nwalters512]

Looks like the failing tests were fixed in #15001.

[nwalters512]

If y'all want to check for a maximally-deduped lockfile in CI (I'd strongly advise this), you can add a npx yarn-deduplicate --check step to CI. Let me know if this is desired and I can add it.

Once you're using Yarn v4, this is built in via yarn dedupe/yarn dedupe --check.

[nwalters512]

I'm splitting this out of #14967 since it was getting a little out of hand in that other PR.

Tests are currently failing, seemingly related to ampproject/remapping#193. It seems like this may only have been fixed in vitest v2? So that might be a blocker for these changes.

There's another strange failure in the packages/browser test:

 FAIL test/eventbuilder.test.ts > extractMessage > should extract message from a WebAssembly.Exception object
AssertionError: expected 'No error message' to be 'wasm exception' // Object.is equality
- Expected
+ Received
- wasm exception
+ No error message
❯ test/eventbuilder.test.ts:188:21
186| 187| const message = extractMessage(wasmException);
188| expect(message).toBe('wasm exception');
| ^
189| });
190| 

However, this also fails for me on the develop branch, so this may not be related to these changes.

[nwalters512]

@mydea I'm unable to reproduce the integration test failures (https://github.com/getsentry/sentry-javascript/actions/runs/12751414906/job/35538905465?pr=14968) locally. I'm frankly not sure why integration tests seem to be performing type checking in the first place. Can you offer any guidance here? Maybe this is related to dependency caching in CI? Thanks!

Edit: I see now that it's testing against TS 3.8, and that I need to run node ./scripts/use-ts-3_8.js locally to reproduce this.

[nwalters512]

It looks like the type errors are occurring because @types/express-serve-static-core uses modern TypeScript features that aren't supported by TypeScript 3.8, e.g.:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/c55a1e4fd5c048683bfd7c55340c78193124d11b/types/express-serve-static-core/index.d.ts#L105

Support for this was only introduced in TypeScript 4.1: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html

This was introduced to those types 4 years ago: DefinitelyTyped/DefinitelyTyped#51262

And as of 2 years ago, TypeScript <=4.0 is no longer supported by DefinitelyTyped: DefinitelyTyped/DefinitelyTyped#62240

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

[nwalters512]

In 30b8213 I updated the TypeScript 3.8 script to use resolutions in package.json to pin the Express types to older versions, which worked for me locally.

[AbhiPrasad]

Marking myself as a reviewer, will take a look ASAP!

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

Because we want to be as a compatible with many users as possible. We said we would support 3.8+ with our 8.x major version, so we need to test to make sure we support it. We often hold support for things much longer than typical LTS for most JS libraries: https://develop.sentry.dev/sdk/philosophy/#compatibility-is-king

[nwalters512]

I'm not sure why things are failing after getting up to date with develop 😢 I'll poke at this tomorrow.

[nwalters512]

Looks like the failing tests were fixed in #15001.

[nwalters512]

If y'all want to check for a maximally-deduped lockfile in CI (I'd strongly advise this), you can add a npx yarn-deduplicate --check step to CI. Let me know if this is desired and I can add it.

Once you're using Yarn v4, this is built in via yarn dedupe/yarn dedupe --check.

[nwalters512]

I'm splitting this out of #14967 since it was getting a little out of hand in that other PR.

Tests are currently failing, seemingly related to ampproject/remapping#193. It seems like this may only have been fixed in vitest v2? So that might be a blocker for these changes.

There's another strange failure in the packages/browser test:

 FAIL test/eventbuilder.test.ts > extractMessage > should extract message from a WebAssembly.Exception object
AssertionError: expected 'No error message' to be 'wasm exception' // Object.is equality
- Expected
+ Received
- wasm exception
+ No error message
❯ test/eventbuilder.test.ts:188:21
186| 187| const message = extractMessage(wasmException);
188| expect(message).toBe('wasm exception');
| ^
189| });
190| 

However, this also fails for me on the develop branch, so this may not be related to these changes.

[nwalters512]

@mydea I'm unable to reproduce the integration test failures (https://github.com/getsentry/sentry-javascript/actions/runs/12751414906/job/35538905465?pr=14968) locally. I'm frankly not sure why integration tests seem to be performing type checking in the first place. Can you offer any guidance here? Maybe this is related to dependency caching in CI? Thanks!

Edit: I see now that it's testing against TS 3.8, and that I need to run node ./scripts/use-ts-3_8.js locally to reproduce this.

[nwalters512]

It looks like the type errors are occurring because @types/express-serve-static-core uses modern TypeScript features that aren't supported by TypeScript 3.8, e.g.:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/c55a1e4fd5c048683bfd7c55340c78193124d11b/types/express-serve-static-core/index.d.ts#L105

Support for this was only introduced in TypeScript 4.1: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html

This was introduced to those types 4 years ago: DefinitelyTyped/DefinitelyTyped#51262

And as of 2 years ago, TypeScript <=4.0 is no longer supported by DefinitelyTyped: DefinitelyTyped/DefinitelyTyped#62240

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

[nwalters512]

In 30b8213 I updated the TypeScript 3.8 script to use resolutions in package.json to pin the Express types to older versions, which worked for me locally.

[AbhiPrasad]

Marking myself as a reviewer, will take a look ASAP!

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

Because we want to be as a compatible with many users as possible. We said we would support 3.8+ with our 8.x major version, so we need to test to make sure we support it. We often hold support for things much longer than typical LTS for most JS libraries: https://develop.sentry.dev/sdk/philosophy/#compatibility-is-king

[nwalters512]

I'm not sure why things are failing after getting up to date with develop 😢 I'll poke at this tomorrow.

[nwalters512]

Looks like the failing tests were fixed in #15001.

[nwalters512]

If y'all want to check for a maximally-deduped lockfile in CI (I'd strongly advise this), you can add a npx yarn-deduplicate --check step to CI. Let me know if this is desired and I can add it.

Once you're using Yarn v4, this is built in via yarn dedupe/yarn dedupe --check.

[nwalters512]

I'm splitting this out of #14967 since it was getting a little out of hand in that other PR.

Tests are currently failing, seemingly related to ampproject/remapping#193. It seems like this may only have been fixed in vitest v2? So that might be a blocker for these changes.

There's another strange failure in the packages/browser test:

 FAIL test/eventbuilder.test.ts > extractMessage > should extract message from a WebAssembly.Exception object
AssertionError: expected 'No error message' to be 'wasm exception' // Object.is equality
- Expected
+ Received
- wasm exception
+ No error message
❯ test/eventbuilder.test.ts:188:21
186| 187| const message = extractMessage(wasmException);
188| expect(message).toBe('wasm exception');
| ^
189| });
190| 

However, this also fails for me on the develop branch, so this may not be related to these changes.

[nwalters512]

@mydea I'm unable to reproduce the integration test failures (https://github.com/getsentry/sentry-javascript/actions/runs/12751414906/job/35538905465?pr=14968) locally. I'm frankly not sure why integration tests seem to be performing type checking in the first place. Can you offer any guidance here? Maybe this is related to dependency caching in CI? Thanks!

Edit: I see now that it's testing against TS 3.8, and that I need to run node ./scripts/use-ts-3_8.js locally to reproduce this.

[nwalters512]

It looks like the type errors are occurring because @types/express-serve-static-core uses modern TypeScript features that aren't supported by TypeScript 3.8, e.g.:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/c55a1e4fd5c048683bfd7c55340c78193124d11b/types/express-serve-static-core/index.d.ts#L105

Support for this was only introduced in TypeScript 4.1: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html

This was introduced to those types 4 years ago: DefinitelyTyped/DefinitelyTyped#51262

And as of 2 years ago, TypeScript <=4.0 is no longer supported by DefinitelyTyped: DefinitelyTyped/DefinitelyTyped#62240

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

[nwalters512]

In 30b8213 I updated the TypeScript 3.8 script to use resolutions in package.json to pin the Express types to older versions, which worked for me locally.

[AbhiPrasad]

Marking myself as a reviewer, will take a look ASAP!

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

Because we want to be as a compatible with many users as possible. We said we would support 3.8+ with our 8.x major version, so we need to test to make sure we support it. We often hold support for things much longer than typical LTS for most JS libraries: https://develop.sentry.dev/sdk/philosophy/#compatibility-is-king

[nwalters512]

I'm not sure why things are failing after getting up to date with develop 😢 I'll poke at this tomorrow.

[nwalters512]

Looks like the failing tests were fixed in #15001.

[nwalters512]

If y'all want to check for a maximally-deduped lockfile in CI (I'd strongly advise this), you can add a npx yarn-deduplicate --check step to CI. Let me know if this is desired and I can add it.

Once you're using Yarn v4, this is built in via yarn dedupe/yarn dedupe --check.

[nwalters512]

I'm splitting this out of #14967 since it was getting a little out of hand in that other PR.

Tests are currently failing, seemingly related to ampproject/remapping#193. It seems like this may only have been fixed in vitest v2? So that might be a blocker for these changes.

There's another strange failure in the packages/browser test:

 FAIL test/eventbuilder.test.ts > extractMessage > should extract message from a WebAssembly.Exception object
AssertionError: expected 'No error message' to be 'wasm exception' // Object.is equality
- Expected
+ Received
- wasm exception
+ No error message
❯ test/eventbuilder.test.ts:188:21
186| 187| const message = extractMessage(wasmException);
188| expect(message).toBe('wasm exception');
| ^
189| });
190| 

However, this also fails for me on the develop branch, so this may not be related to these changes.

[nwalters512]

@mydea I'm unable to reproduce the integration test failures (https://github.com/getsentry/sentry-javascript/actions/runs/12751414906/job/35538905465?pr=14968) locally. I'm frankly not sure why integration tests seem to be performing type checking in the first place. Can you offer any guidance here? Maybe this is related to dependency caching in CI? Thanks!

Edit: I see now that it's testing against TS 3.8, and that I need to run node ./scripts/use-ts-3_8.js locally to reproduce this.

[nwalters512]

It looks like the type errors are occurring because @types/express-serve-static-core uses modern TypeScript features that aren't supported by TypeScript 3.8, e.g.:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/c55a1e4fd5c048683bfd7c55340c78193124d11b/types/express-serve-static-core/index.d.ts#L105

Support for this was only introduced in TypeScript 4.1: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html

This was introduced to those types 4 years ago: DefinitelyTyped/DefinitelyTyped#51262

And as of 2 years ago, TypeScript <=4.0 is no longer supported by DefinitelyTyped: DefinitelyTyped/DefinitelyTyped#62240

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

[nwalters512]

In 30b8213 I updated the TypeScript 3.8 script to use resolutions in package.json to pin the Express types to older versions, which worked for me locally.

[AbhiPrasad]

Marking myself as a reviewer, will take a look ASAP!

Why is Sentry testing against TypeScript 3.8? This version hasn't been supported for a long time, and @types/* packages are no longer guaranteed to be compatible with it.

Because we want to be as a compatible with many users as possible. We said we would support 3.8+ with our 8.x major version, so we need to test to make sure we support it. We often hold support for things much longer than typical LTS for most JS libraries: https://develop.sentry.dev/sdk/philosophy/#compatibility-is-king

[nwalters512]

I'm not sure why things are failing after getting up to date with develop 😢 I'll poke at this tomorrow.

[nwalters512]

Looks like the failing tests were fixed in #15001.

[nwalters512]

If y'all want to check for a maximally-deduped lockfile in CI (I'd strongly advise this), you can add a npx yarn-deduplicate --check step to CI. Let me know if this is desired and I can add it.

Once you're using Yarn v4, this is built in via yarn dedupe/yarn dedupe --check.