💻

• Would you like to work on this feature?

What problem are you trying to solve?

Create a guide for passing cookies from Cloudfront

Describe the solution you'd like

Create a guide for passing cookies from Cloudfront

Describe alternatives you've considered

NA

Documentation, Adoption, Migration Strategy

No response

💻

• Would you like to work on this feature?

What problem are you trying to solve?

Currently, the SSR Lambda handler uses event.requestContext.domainName to determine the domain name. However, when using the Lambda behind CloudFront and API Gateway, this approach always results in the API Gateway URL being used as the host.

Describe the solution you'd like

To address this, I suggest that the handler should also check for the x-forward-host header, which can be configured in CloudFront. If this header is present, its value should be used as the domain name instead of event.requestContext.domainName.

This change will allow the correct CloudFront domain to be used as the host, providing more flexibility and accuracy in environments where the Lambda function is accessed through CloudFront.

Describe alternatives you've considered

We have considered alternatives, but none provide a satisfactory solution to the problem. Our main issue is that auth-astro uses the request URL, which will not work correctly without this change. Without the ability to use the x-forward-host header, the application continues to receive the API Gateway URL instead of the desired CloudFront domain, causing issues in our setup.

Documentation, Adoption, Migration Strategy

I will open a pull request (PR) to implement this feature and hope it will be merged soon. Once merged, I hope a new version of astro-aws will be released to include this enhancement.

💻

• Would you like to work on a fix?

Input code

import { createRequire } from 'module';
const require = createRequire(import.meta.url);

Current and expected behavior

For some reason require is getting declared like this and lambda throws an error with

2023-01-03T19:29:05.509Z	undefined	ERROR	Uncaught Exception 	
{
    "errorType": "Runtime.UserCodeSyntaxError",
    "errorMessage": "SyntaxError: Identifier 'createRequire' has already been declared",
    "stack": [
        "Runtime.UserCodeSyntaxError: SyntaxError: Identifier 'createRequire' has already been declared",
        "    at _loadUserApp (file:///var/runtime/index.mjs:997:17)",
        "    at async UserFunction.js.module.exports.load (file:///var/runtime/index.mjs:1035:21)",
        "    at async start (file:///var/runtime/index.mjs:1200:23)",
        "    at async file:///var/runtime/index.mjs:1206:1"
    ]
}

Environment

    "@astro-aws/adapter": "^0.2.0",
    "@astrojs/image": "^0.12.1",
    "@astrojs/mdx": "^0.14.0",
    "@astrojs/sitemap": "^1.0.0",
    "@astrojs/tailwind": "^2.1.3",
    "astro": "^1.8.0",

Possible solution

No response

Additional context

I will be happy to add you to my repository if that helps debug the issue.

💻

• Would you like to work on this feature?

What problem are you trying to solve?

Astro has a hybrid build mode that prerenders pages if possible. See here.

Describe the solution you'd like

Support it

Describe alternatives you've considered

NA

Documentation, Adoption, Migration Strategy

No response

💻

• Would you like to work on this feature?

What problem are you trying to solve?

trying polyfill process.env

Describe the solution you'd like

simple dump of env into process.env

Describe alternatives you've considered

use banner of esbuild

Documentation, Adoption, Migration Strategy

No response

💻

• Would you like to work on a fix?

Input code

Repo - https://github.com/curiosta/curiosta-website/tree/main/cdk

export class AstroStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const curiostaCert = Certificate.fromCertificateArn(
      this,
      "curiostaCert",
      "arn:aws:acm:us-east-1:615256776167:certificate/47567bde-9915-4b69-9274-8b0f271def89"
    );

    const cachePolicy = new CachePolicy(this, "curiostaCachePolicy", {
      maxTtl: Duration.days(365),
      minTtl: Duration.seconds(5),
      defaultTtl: Duration.minutes(15),
      // queryStringBehavior: CacheQueryStringBehavior.allowList(),
    });

    const astroAws = new AstroAWS(this, "curiosta-website", {
      websiteDir: "../",
      output: "server",
      cdk: {
        cloudfrontDistribution: {
          domainNames: ["curiosta.com"],
          certificate: curiostaCert,
          defaultBehavior: {
            cachePolicy: cachePolicy,
          },
        },
        lambdaFunction: {
          environment: {
            PUBLIC_BASE_URL: "https://store.curiosta.com",
          },
        },
      },
    });

    const curiostaHostedZone = HostedZone.fromLookup(
      this,
      "curiostaHostedZone",
      {
        domainName: "curiosta.com",
      }
    );

    new ARecord(this, "domain-alias", {
      zone: curiostaHostedZone,
      recordName: "curiosta.com",
      target: RecordTarget.fromAlias(
        new CloudFrontTarget(astroAws.cdk.cloudfrontDistribution)
      ),
    });

    if (!astroAws.cdk.lambdaFunction) {
      throw Error("Unable to get lambda ref");
    }

    new CfnOutput(this, "WebsiteDomain", {
      value: astroAws.cdk.cloudfrontDistribution.distributionDomainName,
    });
  }
}

export class CuriostaPipelineStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const pipeline = new CodePipeline(this, "Pipeline", {
      pipelineName: "curiosta",
      codeBuildDefaults: {
        buildEnvironment: {
          buildImage: LinuxBuildImage.STANDARD_6_0,
          computeType: ComputeType.LARGE,
          environmentVariables: {
            NODE_VERSION: {
              value: "16",
            },
          },
        },
      },
      selfMutation: true,
      synth: new ShellStep("Synth", {
        input: CodePipelineSource.gitHub(
          "curiosta/curiosta-website",
          "pipeline"
        ),

        primaryOutputDirectory: "cdk/cdk.out",
        installCommands: ["npm i", "npm i --prefix ./cdk"],
        commands: ["npm run build", "cd cdk", "npx cdk synth"],
      }),
    });

    pipeline.addStage(
      new PipelineStage(this, "prod", {
        env: { account: "615256776167", region: "ap-south-1" },
      })
    );
  }
}

export class PipelineStage extends cdk.Stage {
  constructor(scope: Construct, id: string, props?: cdk.StageProps) {
    super(scope, id, props);

    const astroStack = new AstroStack(this, "CdkStack", {
      stackName: "AstroStack",
      env: { account: "615256776167", region: "ap-south-1" },
    });
  }
}

Current and expected behavior

I am getting:
Resource handler returned message: "Error occurred while GetObject. S3 Error Code: NoSuchKey. S3 Error Message: The specified key does not exist. (Service: Lambda, Status Code: 400, Request ID: 0e05a3a5-9025-45ca-a094-42c5f3fe0355)" (RequestToken: 8c3c19e0-fa5e-ec6b-0263-ced90e7e517f, HandlerErrorCode: InvalidRequest)

Here is the full event log: https://gist.github.com/ShivamJoker/460c0c84df7fdc4de79e9b4ba0cdb588

I have tried enabling and disabling selfMutation

The build seems to work fie on local machine.

Environment

"@astro-aws/constructs": "^0.3.0",
"aws-cdk-lib": "2.75.0",
"astro": "^2.3.0",
"@astro-aws/adapter": "^0.3.0",

Possible solution

Define custom pipeline to run cdk deploy ?

Additional context

No response

💻

• Would you like to work on a fix?

Input code

Source for astro and CDK - https://github.com/LearnAWS-io/Open-Quotes-Website

Current and expected behavior

Search query params doesn't get passed to the lambda.

URL - https://d2cwgta0kas6xp.cloudfront.net/?lastQuote=0f2mA4u1p3E0eqqsDRZuLgxHuHH

Cloudwatch logs:

2023-03-04T10:39:39.240Z	4f3aac49-fe22-4492-9758-2e313559f253	INFO	firstQuoteId null
2023-03-04T10:39:39.240Z	4f3aac49-fe22-4492-9758-2e313559f253	INFO	lastQuoteId null

Also I have disabled the caching

CachePolicy.CACHING_DISABLED

Environment

Astro
"@astro-aws/adapter": "^0.3.0",
"astro": "^2.0.17"

CDK
"@astro-aws/constructs": "^0.3.0",
"aws-cdk-lib": "2.67.0",
"cdk-iam-floyd": "^0.485.0",
"constructs": "^10.0.0",
"source-map-support": "^0.5.21"

Possible solution

No response

Additional context

No response

💻

• Would you like to work on this feature?

What problem are you trying to solve?

I was searching for an adapter to aws and i found this awesome project please update the website here https://astro.build/integrations/?search=astro-aws%2Fadapter.

I will checkout this project and maybe if its possible i can help to write documentation how to use it.

Describe the solution you'd like

Redirect it to do www.docs.astro-aws.org/

Describe alternatives you've considered

-_-

Documentation, Adoption, Migration Strategy

No response

💻

• Would you like to work on a fix?

Input code

I am using the SSR example from astro repo - https://github.com/withastro/astro/tree/main/examples/ssr

const astroWebsite = new AstroAWS(this, "AstroAWSConstruct", {
  output: "edge",
  websiteDir: "../website",
  cdk: {
    cloudfrontDistribution: {
      defaultBehavior: {
        cachePolicy: cachePolicy,
      },
    },
  },
});

Current and expected behavior

The /api endpoint is working fine, however the rendering of homepage is giving me 503 ERROR The request could not be satisfied.

Environment

"@astro-aws/constructs": "^0.3.0",
"aws-cdk-lib": "2.66.1",
"constructs": "^10.0.0",
"@astro-aws/adapter": "^0.3.0",

Possible solution

No idea. Where can I see the rendering log?
Do I need to enable Cloudfront logging?

Additional context

No response

💻

• Would you like to work on a fix?

Input code

I'm building in output: 'hybrid' with the latest [email protected] using the @astro-aws/[email protected] and there's some issue with esbuild configuration.

At the end of the process, the log shows:

17:18:41
 finalizing server assets

17:18:41 [build] Rearranging server assets...
✘ [ERROR] No loader is configured for ".node" files: node_modules/sharp/build/Release/sharp-darwin-arm64v8.node

    node_modules/sharp/lib/sharp.js:10:27:
      10 │   module.exports = require(`../build/Release/sharp-${platformAndArch}.node`);
         ╵                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

✘ [ERROR] Could not resolve require("../vendor/**/*/**/*/versions.json")

    node_modules/sharp/lib/utility.js:58:21:
      58 │   versions = require(`../vendor/${versions.vips}/${platformAndArch}/versions.json`);
         ╵                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

No loader is configured for ".node" files: node_modules/sharp/build/Release/sharp-darwin-arm64v8.node
  Stack trace:
    at failureErrorWithLog (~/node_modules/esbuild/lib/main.js:1650:15)
    at ~/node_modules/esbuild/lib/main.js:1003:52
    at ~/node_modules/esbuild/lib/main.js:1085:16
    at handleIncomingPacket (~/node_modules/esbuild/lib/main.js:763:9)
    at Socket.emit (node:events:513:28)
    at readableAddChunk (node:internal/streams/readable:297:9)
    at Pipe.onStreamRead (node:internal/stream_base_commons:190:23)

Current and expected behavior

It should be possible to build.

Environment

1. Apple Silicon (M2)
2. [email protected] (comes with forced sharp installation)
3. @astro-aws/[email protected]

Possible solution

For now, revert to astro@3 (afaik)

Additional context

I'm going to have a look at esbuild config after filing this ticket, maybe i can have my way with the adapter's options.

💻

• Would you like to work on this feature?

What problem are you trying to solve?

When running the adapter on Astro@3, the message shows at dev:

[astro] The adapter @astro-aws/adapter doesn't provide a feature map. From Astro 3.0, an adapter can provide a feature map. Not providing a feature map will cause an error in Astro 4.0.

Describe the solution you'd like

We need to add a feature map to the adapter so that Astro doesn't complain.

Describe alternatives you've considered

Add an empty feature map to silence the error

Documentation, Adoption, Migration Strategy

No response

💻

• Would you like to work on a fix?

Input code

Astro.cookies.set('cookie1', 'test')
Astro.cookies.delete('cookie2')

Current and expected behavior

Cookies set with Astro.cookies are disregarded during the construction of the LambdaEdge response.
Currently, it is possible to set exactly one cookie using the headers

Astro.response.headers.set('Set-Cookie', 'cookie1=test'), but setting multiple cookies does not work

Astro.response.headers.append('Set-Cookie', 'cookie1=test')
Astro.response.headers.append('Set-Cookie', 'cookie2=undefined; Max-Age: 0')

This will only set the last cookie, Astro recommends to use Astro.cookies.

With this PR, Astro.cookies are respected.

Environment

• newest versions

Possible solution

see PR #62

Additional context

No response

💻

• Would you like to work on a fix?

Input code

In astro.config.mjs with type-checking by typescript try importing the adapter:

// @ts-check

import aws from '@astro-aws/adapter'

Current and expected behavior

TypeScript complains: "Cannot find module '@astro-aws/adapter' or its corresponding type declarations.ts(2307)"

Workaround:

// @ts-expect-error -- package does not correctly export and package types for the default import
Cannot find module '@astro-aws/adapter' or its corresponding type declarations.ts(2307)

Having types is nice especially with an unfamiliar package that doesn't have a lot of documentation yet.

I can see there are .d.ts files within the node_modules/@astro-aws/adapter folder however there seems to be an issue.

I made sure to restart my TS server and then full-on VSCode prior to reporting this issue and it still persists.

Environment

• "@astro-aws/adapter": "^0.4.0"
• "astro": "^3.1.2"
• pnpm 8.7.4
• node 18.17.1
• cdk version not applicable to this issue

Possible solution

Not 100% sure as I don't use turborepo, plus I do see .d.ts files in the package...

However I will note that the config option for ensuring types are emitted for a package is ensuring that declaration: true in tsconfig.json.

I do not see this in https://github.com/lukeshay/astro-aws/blob/main/tsconfig.base.json which both tsconfig.json and tsconfig.build.json in packages/adapter extend from.

TypeScript docs: https://www.typescriptlang.org/tsconfig#declaration
You may also want to consider declarationDir to organize where the type files are placed.

Additional context

No response

💻

• Would you like to work on this feature?

What problem are you trying to solve?

Add support for squoosh

Describe the solution you'd like

Add support for squoosh

Describe alternatives you've considered

None

Documentation, Adoption, Migration Strategy

https://github.com/GoogleChromeLabs/squoosh

💻

• Would you like to work on this feature?

What problem are you trying to solve?

Warning seen in Astro 3.0 when using the adapter:

[astro] The adapter @astro-aws/adapter doesn't provide a feature map. From Astro 3.0, an adapter can provide a feature map. Not providing a feature map will cause an error in Astro 4.0.

Describe the solution you'd like

Provide an AstroFeatureMap per https://docs.astro.build/en/reference/adapter-reference/#building-an-adapter

Describe alternatives you've considered

No alternatives as per warning: "Not providing a feature map will cause an error in Astro 4.0."

Documentation, Adoption, Migration Strategy

Developer experience of astro-aws would presumably be unchanged; this would improve the adapter implementation and make it ready for Astro 4.0.

💻

• Would you like to work on a fix?

Problem

Open https://stackblitz.com/edit/github-7psfac?file=astro.config.mjs and run npm run build. It fails when the vue integration is included.

Running the build with @astro-aws/adapter adapter fails:

~/projects/github-7psfac 6s
❯ npm run build

> @example/[email protected] build
> astro build

07:54:47 [WARN] The currently selected adapter `@astro-aws/adapter` is not compatible with the image service "Sharp".
07:54:47 [vite] Re-optimizing dependencies because vite config has changed
07:54:47 [build] output: "server"
07:54:47 [build] directory: /home/projects/github-7psfac/dist/
07:54:47 [build] adapter: @astro-aws/adapter
07:54:47 [build] Collecting build info...
07:54:47 [build] ✓ Completed in 241ms.
07:54:47 [build] Building server entrypoints...
07:54:48 [build] ✓ Completed in 979ms.

 building client (vite) 
07:54:49 [vite] ✓ 8 modules transformed.
07:54:49 [vite] dist/client/_astro/client.wVF2Fm0T.js  60.60 kB │ gzip: 24.22 kB
07:54:49 [vite] ✓ built in 915ms
07:54:49 
 finalizing server assets 

07:54:49 [build] Rearranging server assets...
Converting circular structure to JSON
    --> starting at object with constructor 'Object'
    |     property 'api' -> object with constructor 'Object'
    |     property 'options' -> object with constructor 'Object'
    |     ...
    |     property 'plugins' -> object with constructor 'Array'
    --- index 32 closes the circle
  Stack trace:
    at JSON.stringify (<anonymous>)
    at Module.runHookBuildDone (file:///home/projects/github-7psfac/node_modules/astro/dist/integrations/index.js:382:58)
    at async AstroBuilder.run (file:///home/projects/github-7psfac/node_modules/astro/dist/core/build/index.js:184:7)
    at async build (file:///home/projects/github-7psfac/node_modules/astro/dist/cli/build/index.js:35:3)
    at async cli (file:///home/projects/github-7psfac/node_modules/astro/dist/cli/index.js:172:5)

Running the build with @astrojs/cloudflare adapter works like expected:

~/projects/github-7psfac 6s
❯ npm run build

> @example/[email protected] build
> astro build

07:51:58 [WARN] [@astrojs/cloudflare] The current configuration does not support image optimization. To allow your project to build with the original, unoptimized images, the image service has been automatically switched to the 'noop' option. See https://docs.astro.build/en/reference/configuration-reference/#imageservice
07:51:59 [vite] Re-optimizing dependencies because vite config has changed
07:51:59 [build] output: "server"
07:51:59 [build] directory: /home/projects/github-7psfac/dist/
07:51:59 [build] adapter: @astrojs/cloudflare
07:51:59 [build] Collecting build info...
07:51:59 [build] ✓ Completed in 232ms.
07:51:59 [build] Building server entrypoints...
07:51:59 [build] ✓ Completed in 742ms.

 building client (vite) 
07:52:00 [vite] ✓ 8 modules transformed.
07:52:00 [vite] dist/_astro/client.wVF2Fm0T.js  60.60 kB │ gzip: 24.22 kB
07:52:00 [vite] ✓ built in 919ms
07:52:00 
 finalizing server assets 

07:52:00 [build] Rearranging server assets...
07:52:01 [build] Server built in 2.47s
07:52:01 [build] Complete!

Environment

• @astro-aws/adapter: 0.5.0
• astro: 4.2.4
• @astrojs/vue: 4.0.8
• vue: 3.4.15

💻

• Would you like to work on this feature?

What problem are you trying to solve?

i'm trying to support local development

Describe the solution you'd like

for astro preview to work. i'm thinking maybe reusing parts of the code at https://github.com/evolv-ai/serverless-offline-edge-lambda could be a suitable solution.

Describe alternatives you've considered

using serverless just for testing but it's heavy

Documentation, Adoption, Migration Strategy

No response

💻

• Would you like to work on a fix?

Input code

src/lambda/tests/helpers.test.ts > helpers > createFunctionResponse > creates function response

Current and expected behavior

Not to see said error

Environment

• Node: 16

Possible solution

No response

Additional context

https://github.com/lukeshay/astro-aws/actions/runs/3943816346/jobs/6749124685

Here is the code -

export class AwsClimateTypesStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const res = new AstroAWSConstruct(this, "AstroAWSConstruct", {
      output: "server",
      websiteDir: "../",
    });
    new CfnOutput(this, "url", {
      value: res.distribution.domainName,
    });
  }
}

The URL - https://dv8s6vlgw84po.cloudfront.net/
it should randomize the question every-time we re-load the page

This works perfect on Cloudflare pages - https://climatetypes.com/

💻

• Would you like to work on this feature?

What problem are you trying to solve?

The first party astro node adapter supports providing Astro.locals when ran in middleware mode. It would be convinient to implement it for the aws adapter as well to enable easily passing data from the handler to Astro.

https://docs.astro.build/en/guides/middleware/

Describe the solution you'd like

Add a new optional parameter that enables supplying Astro.locals

Describe alternatives you've considered

As a workaround you can write Astro middlewares that can make request to s3 buckets for instance. (The problem is mixing responsibilities with this approach)

Documentation, Adoption, Migration Strategy

No response

💻

• Would you like to work on this feature?

What problem are you trying to solve?

Use other tools

Describe the solution you'd like

Inject the following into the adapter if the user wants

• Logger
• Tracer
• Metrics

Describe alternatives you've considered

Use other tools

Documentation, Adoption, Migration Strategy

No response

💻

• Would you like to work on a fix?

Input code

Something like this:

---
import { Image } from 'astro:assets'
import exampleImg from '../assets/image.png'
---
 
<Image src={exampleImg} />

Current and expected behavior

During build the src attribute is correctly set to use the image server (eg, /_image?href=%2F_astro%2Fimage.Y0Z6qWya.png&f=webp), but when rendering the lambda returns a 500 error, rather than the image itself.

In the server logs, we see this error:

[ERROR] TypeError: Component.render is not a function
    at Object.renderToStaticMarkup (file:///var/task/entry.mjs:55:30)
    at renderFrameworkComponent (file:///var/task/entry.mjs:1554:68)
    at async renderComponent (file:///var/task/entry.mjs:1744:10)
    at async renderComponentToString (file:///var/task/entry.mjs:1787:28)
    at async renderPage (file:///var/task/entry.mjs:1950:17)
    at async lastNext (file:///var/task/entry.mjs:23261:25)
    at async callMiddleware (file:///var/task/entry.mjs:22622:10)
    at async _RenderContext.render (file:///var/task/entry.mjs:23284:22)
    at async _NodeApp.render (file:///var/task/entry.mjs:23777:18)
    at async handler2 (file:///var/task/entry.mjs:27026:22)

Environment

• Astro AWS version: 0.6.0
• Astro version: 4.5.13
• Node.js: 20.11.1
• Yarn: 1.22.19
• AWS CDK: N/A (don't use the CDK constructs)

Possible solution

No response

Additional context

I originally wondered if this was an issue with using sharp or swoosh, so followed the docs to just use a passthrough service but that didn't seem to help.

For now, we're able to bypass this by using an img tag and referencing the src attribute:

---
import exampleImg from '../assets/image.png'
---

<img src={exampleImg.src} />

💻

• Would you like to work on this feature?

What problem are you trying to solve?

Make page response faster

Describe the solution you'd like

Right now it seems the Construct uses normal Lambdas, if we could use Edge lambdas to boost the speed it will be great.

Describe alternatives you've considered

Nothing

Documentation, Adoption, Migration Strategy

No response

• Where to find things to work on
• How to deploy the website to your own AWS account

💻

• Would you like to work on this feature?

What problem are you trying to solve?

Create a guide for passing query strings from Cloudfront

Describe the solution you'd like

Create a guide for passing query strings from Cloudfront

Describe alternatives you've considered

NA

Documentation, Adoption, Migration Strategy

No response

💻

• Would you like to work on this feature?

What problem are you trying to solve?

Add sharp support for SSR

Describe the solution you'd like

Add sharp support for SSR

Describe alternatives you've considered

None

Documentation, Adoption, Migration Strategy

No response

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Datasource	Name	Replacement PR?
npm	@astrojs/webapi

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency starlight-links-validator to ^0.10.0
• fix(deps): update dependency @astrojs/starlight to ^0.26.0
• chore(deps): update actions/stale action to v9
• chore(deps): update dependency node to v20 (node, @types/node)
• chore(deps): update oven-sh/setup-bun action to v2
• fix(deps): update dependency @astrojs/webapi to v3
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update actions/checkout action to v4

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Description

ESLint is not working at the moment.

💻

• Would you like to work on this feature?

What problem are you trying to solve?

AWS added support for streaming http responses . This is a vital feature and would be a huge performance boost for ssr runtimes.

Describe the solution you'd like

Either the exported handler should not wait for the response stream to finish and expose the response to a wrapping handler provided by the consumer, or the package should implement first class support using ‘awslambda.streamifyResponse’ decorator.

Describe alternatives you've considered

None, this package currently is not suited for streaming reponses and there are no workarounds.

Documentation, Adoption, Migration Strategy

No response