feat(deno): Stop inlining types from core by mydea · Pull Request #14729 · getsentry/sentry-javascript

mydea · 2024-12-16T10:29:24Z

Extracted out from #14721

Today, we inline all the types into deno/build/index.d.ts. This used to work "OK" previously, where all the types came from @sentry/types and where thus all "simple types".

If we want to replace some of this with actual classes, e.g. Scope or Client classes, this starts to fail, because now we have separate definitions that do not match.

So to fix this, we now stop inlining all the types, but instead re-export them from @sentry/core. While at this, I also updated the test setup to ignore utils/types and just use core for everything.

With this change, deno/build/index.d.ts looks something like this:

import*as_sentry_corefrom'@sentry/core';import{BaseTransportOptions,Options,TracePropagationTargets,ClientOptions,ServerRuntimeClient,Integration,Client}from'@sentry/core';export{ ... }from'@sentry/core';// additional types from deno go here...

I do not think this should be breaking, but 🤷 hard to say for sure with these things.

lforst · 2024-12-16T11:51:54Z

I cannot remember whether we can externalize core in the declarations or not. From my pov it seems fine. @timfish do you remember?

timfish · 2024-12-16T11:54:55Z

I'll be back at my desk in about an hour and I'll take a proper look

timfish · 2024-12-16T13:17:01Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.

Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

mydea · 2024-12-16T13:19:31Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.
Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

This sounds reasonable to me! Making this easier & more streamlined 👍

I noticed that after #14729, now tests started failing 😬 The reason: * We run `deno check ./build/index.mjs` * This checks the types, but we now do not inline those anymore into the generated `./build/index.d.ts` file * Instead, we just import them from `@sentry/core` * Now `deno check` downloads the latest version of core into a local tmp folder and uses this for checking * But there are different exports there than locally, leading to test failures 😬 this PR simple kills the type tests - not sure if we need them/they are needed, but I can't think of a different way to make this work, there isn't really a way (as far as I see?) to tell `deno check` to consider a dependency from a local path instead 😬

mydea · 2024-12-16T10:29:24Z

Extracted out from #14721

Today, we inline all the types into deno/build/index.d.ts. This used to work "OK" previously, where all the types came from @sentry/types and where thus all "simple types".

If we want to replace some of this with actual classes, e.g. Scope or Client classes, this starts to fail, because now we have separate definitions that do not match.

So to fix this, we now stop inlining all the types, but instead re-export them from @sentry/core. While at this, I also updated the test setup to ignore utils/types and just use core for everything.

With this change, deno/build/index.d.ts looks something like this:

import*as_sentry_corefrom'@sentry/core';import{BaseTransportOptions,Options,TracePropagationTargets,ClientOptions,ServerRuntimeClient,Integration,Client}from'@sentry/core';export{ ... }from'@sentry/core';// additional types from deno go here...

I do not think this should be breaking, but 🤷 hard to say for sure with these things.

lforst · 2024-12-16T11:51:54Z

I cannot remember whether we can externalize core in the declarations or not. From my pov it seems fine. @timfish do you remember?

timfish · 2024-12-16T11:54:55Z

I'll be back at my desk in about an hour and I'll take a proper look

timfish · 2024-12-16T13:17:01Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.

Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

mydea · 2024-12-16T13:19:31Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.
Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

This sounds reasonable to me! Making this easier & more streamlined 👍

I noticed that after #14729, now tests started failing 😬 The reason: * We run `deno check ./build/index.mjs` * This checks the types, but we now do not inline those anymore into the generated `./build/index.d.ts` file * Instead, we just import them from `@sentry/core` * Now `deno check` downloads the latest version of core into a local tmp folder and uses this for checking * But there are different exports there than locally, leading to test failures 😬 this PR simple kills the type tests - not sure if we need them/they are needed, but I can't think of a different way to make this work, there isn't really a way (as far as I see?) to tell `deno check` to consider a dependency from a local path instead 😬

mydea · 2024-12-16T10:29:24Z

Extracted out from #14721

Today, we inline all the types into deno/build/index.d.ts. This used to work "OK" previously, where all the types came from @sentry/types and where thus all "simple types".

If we want to replace some of this with actual classes, e.g. Scope or Client classes, this starts to fail, because now we have separate definitions that do not match.

So to fix this, we now stop inlining all the types, but instead re-export them from @sentry/core. While at this, I also updated the test setup to ignore utils/types and just use core for everything.

With this change, deno/build/index.d.ts looks something like this:

import*as_sentry_corefrom'@sentry/core';import{BaseTransportOptions,Options,TracePropagationTargets,ClientOptions,ServerRuntimeClient,Integration,Client}from'@sentry/core';export{ ... }from'@sentry/core';// additional types from deno go here...

I do not think this should be breaking, but 🤷 hard to say for sure with these things.

lforst · 2024-12-16T11:51:54Z

I cannot remember whether we can externalize core in the declarations or not. From my pov it seems fine. @timfish do you remember?

timfish · 2024-12-16T11:54:55Z

I'll be back at my desk in about an hour and I'll take a proper look

timfish · 2024-12-16T13:17:01Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.

Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

mydea · 2024-12-16T13:19:31Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.
Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

This sounds reasonable to me! Making this easier & more streamlined 👍

I noticed that after #14729, now tests started failing 😬 The reason: * We run `deno check ./build/index.mjs` * This checks the types, but we now do not inline those anymore into the generated `./build/index.d.ts` file * Instead, we just import them from `@sentry/core` * Now `deno check` downloads the latest version of core into a local tmp folder and uses this for checking * But there are different exports there than locally, leading to test failures 😬 this PR simple kills the type tests - not sure if we need them/they are needed, but I can't think of a different way to make this work, there isn't really a way (as far as I see?) to tell `deno check` to consider a dependency from a local path instead 😬

mydea · 2024-12-16T10:29:24Z

Extracted out from #14721

Today, we inline all the types into deno/build/index.d.ts. This used to work "OK" previously, where all the types came from @sentry/types and where thus all "simple types".

If we want to replace some of this with actual classes, e.g. Scope or Client classes, this starts to fail, because now we have separate definitions that do not match.

So to fix this, we now stop inlining all the types, but instead re-export them from @sentry/core. While at this, I also updated the test setup to ignore utils/types and just use core for everything.

With this change, deno/build/index.d.ts looks something like this:

import*as_sentry_corefrom'@sentry/core';import{BaseTransportOptions,Options,TracePropagationTargets,ClientOptions,ServerRuntimeClient,Integration,Client}from'@sentry/core';export{ ... }from'@sentry/core';// additional types from deno go here...

I do not think this should be breaking, but 🤷 hard to say for sure with these things.

lforst · 2024-12-16T11:51:54Z

I cannot remember whether we can externalize core in the declarations or not. From my pov it seems fine. @timfish do you remember?

timfish · 2024-12-16T11:54:55Z

I'll be back at my desk in about an hour and I'll take a proper look

timfish · 2024-12-16T13:17:01Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.

Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

mydea · 2024-12-16T13:19:31Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.
Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

This sounds reasonable to me! Making this easier & more streamlined 👍

I noticed that after #14729, now tests started failing 😬 The reason: * We run `deno check ./build/index.mjs` * This checks the types, but we now do not inline those anymore into the generated `./build/index.d.ts` file * Instead, we just import them from `@sentry/core` * Now `deno check` downloads the latest version of core into a local tmp folder and uses this for checking * But there are different exports there than locally, leading to test failures 😬 this PR simple kills the type tests - not sure if we need them/they are needed, but I can't think of a different way to make this work, there isn't really a way (as far as I see?) to tell `deno check` to consider a dependency from a local path instead 😬

mydea · 2024-12-16T10:29:24Z

Extracted out from #14721

Today, we inline all the types into deno/build/index.d.ts. This used to work "OK" previously, where all the types came from @sentry/types and where thus all "simple types".

If we want to replace some of this with actual classes, e.g. Scope or Client classes, this starts to fail, because now we have separate definitions that do not match.

So to fix this, we now stop inlining all the types, but instead re-export them from @sentry/core. While at this, I also updated the test setup to ignore utils/types and just use core for everything.

With this change, deno/build/index.d.ts looks something like this:

import*as_sentry_corefrom'@sentry/core';import{BaseTransportOptions,Options,TracePropagationTargets,ClientOptions,ServerRuntimeClient,Integration,Client}from'@sentry/core';export{ ... }from'@sentry/core';// additional types from deno go here...

I do not think this should be breaking, but 🤷 hard to say for sure with these things.

lforst · 2024-12-16T11:51:54Z

I cannot remember whether we can externalize core in the declarations or not. From my pov it seems fine. @timfish do you remember?

timfish · 2024-12-16T11:54:55Z

I'll be back at my desk in about an hour and I'll take a proper look

timfish · 2024-12-16T13:17:01Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.

Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

mydea · 2024-12-16T13:19:31Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.
Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

This sounds reasonable to me! Making this easier & more streamlined 👍

I noticed that after #14729, now tests started failing 😬 The reason: * We run `deno check ./build/index.mjs` * This checks the types, but we now do not inline those anymore into the generated `./build/index.d.ts` file * Instead, we just import them from `@sentry/core` * Now `deno check` downloads the latest version of core into a local tmp folder and uses this for checking * But there are different exports there than locally, leading to test failures 😬 this PR simple kills the type tests - not sure if we need them/they are needed, but I can't think of a different way to make this work, there isn't really a way (as far as I see?) to tell `deno check` to consider a dependency from a local path instead 😬

mydea · 2024-12-16T10:29:24Z

Extracted out from #14721

Today, we inline all the types into deno/build/index.d.ts. This used to work "OK" previously, where all the types came from @sentry/types and where thus all "simple types".

If we want to replace some of this with actual classes, e.g. Scope or Client classes, this starts to fail, because now we have separate definitions that do not match.

So to fix this, we now stop inlining all the types, but instead re-export them from @sentry/core. While at this, I also updated the test setup to ignore utils/types and just use core for everything.

With this change, deno/build/index.d.ts looks something like this:

import*as_sentry_corefrom'@sentry/core';import{BaseTransportOptions,Options,TracePropagationTargets,ClientOptions,ServerRuntimeClient,Integration,Client}from'@sentry/core';export{ ... }from'@sentry/core';// additional types from deno go here...

I do not think this should be breaking, but 🤷 hard to say for sure with these things.

lforst · 2024-12-16T11:51:54Z

I cannot remember whether we can externalize core in the declarations or not. From my pov it seems fine. @timfish do you remember?

timfish · 2024-12-16T11:54:55Z

I'll be back at my desk in about an hour and I'll take a proper look

timfish · 2024-12-16T13:17:01Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.

Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

mydea · 2024-12-16T13:19:31Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.
Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

This sounds reasonable to me! Making this easier & more streamlined 👍

I noticed that after #14729, now tests started failing 😬 The reason: * We run `deno check ./build/index.mjs` * This checks the types, but we now do not inline those anymore into the generated `./build/index.d.ts` file * Instead, we just import them from `@sentry/core` * Now `deno check` downloads the latest version of core into a local tmp folder and uses this for checking * But there are different exports there than locally, leading to test failures 😬 this PR simple kills the type tests - not sure if we need them/they are needed, but I can't think of a different way to make this work, there isn't really a way (as far as I see?) to tell `deno check` to consider a dependency from a local path instead 😬

mydea · 2024-12-16T10:29:24Z

Extracted out from #14721

Today, we inline all the types into deno/build/index.d.ts. This used to work "OK" previously, where all the types came from @sentry/types and where thus all "simple types".

If we want to replace some of this with actual classes, e.g. Scope or Client classes, this starts to fail, because now we have separate definitions that do not match.

So to fix this, we now stop inlining all the types, but instead re-export them from @sentry/core. While at this, I also updated the test setup to ignore utils/types and just use core for everything.

With this change, deno/build/index.d.ts looks something like this:

import*as_sentry_corefrom'@sentry/core';import{BaseTransportOptions,Options,TracePropagationTargets,ClientOptions,ServerRuntimeClient,Integration,Client}from'@sentry/core';export{ ... }from'@sentry/core';// additional types from deno go here...

I do not think this should be breaking, but 🤷 hard to say for sure with these things.

lforst · 2024-12-16T11:51:54Z

I cannot remember whether we can externalize core in the declarations or not. From my pov it seems fine. @timfish do you remember?

timfish · 2024-12-16T11:54:55Z

I'll be back at my desk in about an hour and I'll take a proper look

timfish · 2024-12-16T13:17:01Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.

Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

mydea · 2024-12-16T13:19:31Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.
Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

This sounds reasonable to me! Making this easier & more streamlined 👍

I noticed that after #14729, now tests started failing 😬 The reason: * We run `deno check ./build/index.mjs` * This checks the types, but we now do not inline those anymore into the generated `./build/index.d.ts` file * Instead, we just import them from `@sentry/core` * Now `deno check` downloads the latest version of core into a local tmp folder and uses this for checking * But there are different exports there than locally, leading to test failures 😬 this PR simple kills the type tests - not sure if we need them/they are needed, but I can't think of a different way to make this work, there isn't really a way (as far as I see?) to tell `deno check` to consider a dependency from a local path instead 😬

mydea · 2024-12-16T10:29:24Z

Extracted out from #14721

Today, we inline all the types into deno/build/index.d.ts. This used to work "OK" previously, where all the types came from @sentry/types and where thus all "simple types".

If we want to replace some of this with actual classes, e.g. Scope or Client classes, this starts to fail, because now we have separate definitions that do not match.

So to fix this, we now stop inlining all the types, but instead re-export them from @sentry/core. While at this, I also updated the test setup to ignore utils/types and just use core for everything.

With this change, deno/build/index.d.ts looks something like this:

import*as_sentry_corefrom'@sentry/core';import{BaseTransportOptions,Options,TracePropagationTargets,ClientOptions,ServerRuntimeClient,Integration,Client}from'@sentry/core';export{ ... }from'@sentry/core';// additional types from deno go here...

I do not think this should be breaking, but 🤷 hard to say for sure with these things.

lforst · 2024-12-16T11:51:54Z

I cannot remember whether we can externalize core in the declarations or not. From my pov it seems fine. @timfish do you remember?

timfish · 2024-12-16T11:54:55Z

I'll be back at my desk in about an hour and I'll take a proper look

timfish · 2024-12-16T13:17:01Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.

Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

mydea · 2024-12-16T13:19:31Z

I think we bundled the code (and types) for Deno because we were publishing to (the now deprecated) deno.land registry.
Deno 2 has almost perfect node/npm support so for v9 we could drop Deno v1 support and just publish to npm without any bundling of code or types?

This sounds reasonable to me! Making this easier & more streamlined 👍

I noticed that after #14729, now tests started failing 😬 The reason: * We run `deno check ./build/index.mjs` * This checks the types, but we now do not inline those anymore into the generated `./build/index.d.ts` file * Instead, we just import them from `@sentry/core` * Now `deno check` downloads the latest version of core into a local tmp folder and uses this for checking * But there are different exports there than locally, leading to test failures 😬 this PR simple kills the type tests - not sure if we need them/they are needed, but I can't think of a different way to make this work, there isn't really a way (as far as I see?) to tell `deno check` to consider a dependency from a local path instead 😬

mydea requested review from AbhiPrasad, lforst and timfish December 16, 2024 10:29

mydea self-assigned this Dec 16, 2024

mydea changed the title ~~feat(deno): Stop inlining types~~feat(deno): Stop inlining types from coreDec 16, 2024

feat(deno): Stop inlining types
12612b4

mydea force-pushed the fn/deno-types branch from 67a45e1 to 12612b4Compare December 16, 2024 10:32

mydea added 3 commits December 16, 2024 11:40

fix clean
501d451

fix test
5d9b8b4

fix linting
8936608

mydea added 2 commits December 16, 2024 13:43

fix tests??
20342ef

fix one more?
d8b2dd2

mydea added 2 commits December 16, 2024 14:20

fix formatting
df35078

remove deno test build stuff
ffcf3ae

timfish approved these changes Dec 16, 2024
View reviewed changes

AbhiPrasad approved these changes Dec 16, 2024
View reviewed changes

mydea merged commit 88f486c into developDec 16, 2024

mydea deleted the fn/deno-types branch December 16, 2024 15:19

mydea mentioned this pull request Dec 16, 2024
chore(deno): Stop testing types #14738
Merged

mydea requested review from AbhiPrasad, lforst and timfish December 16, 2024 10:29

mydea self-assigned this Dec 16, 2024

mydea changed the title ~~feat(deno): Stop inlining types~~feat(deno): Stop inlining types from coreDec 16, 2024

feat(deno): Stop inlining types
12612b4

mydea force-pushed the fn/deno-types branch from 67a45e1 to 12612b4Compare December 16, 2024 10:32

mydea added 3 commits December 16, 2024 11:40

fix clean
501d451

fix test
5d9b8b4

fix linting
8936608

mydea added 2 commits December 16, 2024 13:43

fix tests??
20342ef

fix one more?
d8b2dd2

mydea added 2 commits December 16, 2024 14:20

fix formatting
df35078

remove deno test build stuff
ffcf3ae

timfish approved these changes Dec 16, 2024
View reviewed changes

AbhiPrasad approved these changes Dec 16, 2024
View reviewed changes

mydea merged commit 88f486c into developDec 16, 2024

mydea deleted the fn/deno-types branch December 16, 2024 15:19

mydea mentioned this pull request Dec 16, 2024
chore(deno): Stop testing types #14738
Merged

mydea requested review from AbhiPrasad, lforst and timfish December 16, 2024 10:29

mydea self-assigned this Dec 16, 2024

mydea changed the title ~~feat(deno): Stop inlining types~~feat(deno): Stop inlining types from coreDec 16, 2024

feat(deno): Stop inlining types
12612b4

mydea force-pushed the fn/deno-types branch from 67a45e1 to 12612b4Compare December 16, 2024 10:32

mydea added 3 commits December 16, 2024 11:40

fix clean
501d451

fix test
5d9b8b4

fix linting
8936608

mydea added 2 commits December 16, 2024 13:43

fix tests??
20342ef

fix one more?
d8b2dd2

mydea added 2 commits December 16, 2024 14:20

fix formatting
df35078

remove deno test build stuff
ffcf3ae

timfish approved these changes Dec 16, 2024
View reviewed changes

AbhiPrasad approved these changes Dec 16, 2024
View reviewed changes

mydea merged commit 88f486c into developDec 16, 2024

mydea deleted the fn/deno-types branch December 16, 2024 15:19

mydea mentioned this pull request Dec 16, 2024
chore(deno): Stop testing types #14738
Merged

mydea requested review from AbhiPrasad, lforst and timfish December 16, 2024 10:29

mydea self-assigned this Dec 16, 2024

mydea changed the title ~~feat(deno): Stop inlining types~~feat(deno): Stop inlining types from coreDec 16, 2024

feat(deno): Stop inlining types
12612b4

mydea force-pushed the fn/deno-types branch from 67a45e1 to 12612b4Compare December 16, 2024 10:32

mydea added 3 commits December 16, 2024 11:40

fix clean
501d451

fix test
5d9b8b4

fix linting
8936608

mydea added 2 commits December 16, 2024 13:43

fix tests??
20342ef

fix one more?
d8b2dd2

mydea added 2 commits December 16, 2024 14:20

fix formatting
df35078

remove deno test build stuff
ffcf3ae

timfish approved these changes Dec 16, 2024
View reviewed changes

AbhiPrasad approved these changes Dec 16, 2024
View reviewed changes

mydea merged commit 88f486c into developDec 16, 2024

mydea deleted the fn/deno-types branch December 16, 2024 15:19

mydea mentioned this pull request Dec 16, 2024
chore(deno): Stop testing types #14738
Merged

mydea requested review from AbhiPrasad, lforst and timfish December 16, 2024 10:29

mydea self-assigned this Dec 16, 2024

mydea changed the title ~~feat(deno): Stop inlining types~~feat(deno): Stop inlining types from coreDec 16, 2024

feat(deno): Stop inlining types
12612b4

mydea force-pushed the fn/deno-types branch from 67a45e1 to 12612b4Compare December 16, 2024 10:32

mydea added 3 commits December 16, 2024 11:40

fix clean
501d451

fix test
5d9b8b4

fix linting
8936608

mydea added 2 commits December 16, 2024 13:43

fix tests??
20342ef

fix one more?
d8b2dd2

mydea added 2 commits December 16, 2024 14:20

fix formatting
df35078

remove deno test build stuff
ffcf3ae

timfish approved these changes Dec 16, 2024
View reviewed changes

AbhiPrasad approved these changes Dec 16, 2024
View reviewed changes

mydea merged commit 88f486c into developDec 16, 2024

mydea deleted the fn/deno-types branch December 16, 2024 15:19

mydea mentioned this pull request Dec 16, 2024
chore(deno): Stop testing types #14738
Merged

mydea requested review from AbhiPrasad, lforst and timfish December 16, 2024 10:29

mydea self-assigned this Dec 16, 2024

mydea changed the title ~~feat(deno): Stop inlining types~~feat(deno): Stop inlining types from coreDec 16, 2024

feat(deno): Stop inlining types
12612b4

mydea force-pushed the fn/deno-types branch from 67a45e1 to 12612b4Compare December 16, 2024 10:32

mydea added 3 commits December 16, 2024 11:40

fix clean
501d451

fix test
5d9b8b4

fix linting
8936608

mydea added 2 commits December 16, 2024 13:43

fix tests??
20342ef

fix one more?
d8b2dd2

mydea added 2 commits December 16, 2024 14:20

fix formatting
df35078

remove deno test build stuff
ffcf3ae

timfish approved these changes Dec 16, 2024
View reviewed changes

AbhiPrasad approved these changes Dec 16, 2024
View reviewed changes

mydea merged commit 88f486c into developDec 16, 2024

mydea deleted the fn/deno-types branch December 16, 2024 15:19

mydea mentioned this pull request Dec 16, 2024
chore(deno): Stop testing types #14738
Merged

mydea requested review from AbhiPrasad, lforst and timfish December 16, 2024 10:29

mydea self-assigned this Dec 16, 2024

mydea changed the title ~~feat(deno): Stop inlining types~~feat(deno): Stop inlining types from coreDec 16, 2024

feat(deno): Stop inlining types
12612b4

mydea force-pushed the fn/deno-types branch from 67a45e1 to 12612b4Compare December 16, 2024 10:32

mydea added 3 commits December 16, 2024 11:40

fix clean
501d451

fix test
5d9b8b4

fix linting
8936608

mydea added 2 commits December 16, 2024 13:43

fix tests??
20342ef

fix one more?
d8b2dd2

mydea added 2 commits December 16, 2024 14:20

fix formatting
df35078

remove deno test build stuff
ffcf3ae

timfish approved these changes Dec 16, 2024
View reviewed changes

AbhiPrasad approved these changes Dec 16, 2024
View reviewed changes

mydea merged commit 88f486c into developDec 16, 2024

mydea deleted the fn/deno-types branch December 16, 2024 15:19

mydea mentioned this pull request Dec 16, 2024
chore(deno): Stop testing types #14738
Merged

mydea requested review from AbhiPrasad, lforst and timfish December 16, 2024 10:29

mydea self-assigned this Dec 16, 2024

mydea changed the title ~~feat(deno): Stop inlining types~~feat(deno): Stop inlining types from coreDec 16, 2024

feat(deno): Stop inlining types
12612b4

mydea force-pushed the fn/deno-types branch from 67a45e1 to 12612b4Compare December 16, 2024 10:32

mydea added 3 commits December 16, 2024 11:40

fix clean
501d451

fix test
5d9b8b4

fix linting
8936608

mydea added 2 commits December 16, 2024 13:43

fix tests??
20342ef

fix one more?
d8b2dd2

mydea added 2 commits December 16, 2024 14:20

fix formatting
df35078

remove deno test build stuff
ffcf3ae

timfish approved these changes Dec 16, 2024
View reviewed changes

AbhiPrasad approved these changes Dec 16, 2024
View reviewed changes

mydea merged commit 88f486c into developDec 16, 2024

mydea deleted the fn/deno-types branch December 16, 2024 15:19

mydea mentioned this pull request Dec 16, 2024
chore(deno): Stop testing types #14738
Merged

Uh oh!

Uh oh!

Conversation

mydea commented Dec 16, 2024

Uh oh!

lforst commented Dec 16, 2024

Uh oh!

timfish commented Dec 16, 2024

Uh oh!

timfish commented Dec 16, 2024

Uh oh!

mydea commented Dec 16, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

mydea commented Dec 16, 2024

Uh oh!

lforst commented Dec 16, 2024

Uh oh!

timfish commented Dec 16, 2024

Uh oh!

timfish commented Dec 16, 2024

Uh oh!

mydea commented Dec 16, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

mydea commented Dec 16, 2024

Uh oh!

lforst commented Dec 16, 2024

Uh oh!

timfish commented Dec 16, 2024

Uh oh!

timfish commented Dec 16, 2024

Uh oh!

mydea commented Dec 16, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

mydea commented Dec 16, 2024

Uh oh!

lforst commented Dec 16, 2024

Uh oh!

timfish commented Dec 16, 2024

Uh oh!

timfish commented Dec 16, 2024

Uh oh!

mydea commented Dec 16, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects