Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

chore(deps): update dependency wrangler to v3.19.0 [security] #9

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore(deps): update dependency wrangler to v3.19.0 [security] #9

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Feb 25, 2024

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
wrangler (source) 3.0.0 -> 3.19.0 age adoption passing confidence

GitHub Vulnerability Alerts

CVE-2023-7080

Impact

The V8 inspector intentionally allows arbitrary code execution within the Workers sandbox for debugging. wrangler dev would previously start an inspector server listening on all network interfaces. This would allow an attacker on the local network to connect to the inspector and run arbitrary code. Additionally, the inspector server did not validate Origin/Host headers, granting an attacker that can trick any user on the local network into opening a malicious website the ability to run code. If wrangler dev --remote was being used, an attacker could access production resources if they were bound to the worker.

Patches

This issue was fixed in [email protected] and [email protected]. Whilst wrangler dev's inspector server listens on local interfaces by default as of [email protected], an SSRF vulnerability in miniflare allowed access from the local network until [email protected]. [email protected] and [email protected] introduced validation for the Origin/Host headers.

Workarounds

Unfortunately, Wrangler doesn't provide any configuration for which host that inspector server should listen on. Please upgrade to at least [email protected], and configure Wrangler to listen on local interfaces instead with wrangler dev --ip 127.0.0.1 to prevent SSRF. This removes the local network as an attack vector, but does not prevent an attack from visiting a malicious website.

References

Release Notes

cloudflare/workers-sdk (wrangler)

v3.19.0

Compare Source

Minor Changes

  • #​4547 86c81ff0 Thanks @​mrbbot! - fix: listen on IPv4 loopback only by default on Windows

    Due to a known issue, workerd will only listen on the IPv4 loopback address 127.0.0.1 when it's asked to listen on localhost. On Node.js > 17, localhost will resolve to the IPv6 loopback address, meaning requests to workerd would fail. This change switches to using the IPv4 loopback address throughout Wrangler on Windows, while workerd#1408 gets fixed.

  • #​4535 29df8e17 Thanks @​mrbbot! - Reintroduces some internal refactorings of wrangler dev servers (including wrangler dev, wrangler dev --remote, and unstable_dev()).

    These changes were released in 3.13.0 and reverted in 3.13.1 -- we believe the changes are now more stable and ready for release again.

    There are no changes required for developers to opt-in. Improvements include:

    • fewer 'address in use' errors upon reloads
    • upon config/source file changes, requests are buffered to guarantee the response is from the new version of the Worker
Patch Changes
  • #​4521 6c5bc704 Thanks @​zebp! - fix: init from dash specifying explicit usage model in wrangler.toml for standard users

  • #​4550 63708a94 Thanks @​mrbbot! - fix: validate Host and Orgin headers where appropriate

    Host and Origin headers are now checked when connecting to the inspector and Miniflare's magic proxy. If these don't match what's expected, the request will fail.

  • Updated dependencies [71fb0b86, 63708a94]:

v3.18.0

Compare Source

Minor Changes

  • #​4532 311ffbd5 Thanks @​mrbbot! - fix: change wrangler (pages) dev to listen on localhost by default

    Previously, Wrangler listened on all interfaces (*) by default. This change switches wrangler (pages) dev to just listen on local interfaces. Whilst this is technically a breaking change, we've decided the security benefits outweigh the potential disruption caused. If you need to access your dev server from another device on your network, you can use wrangler (pages) dev --ip * to restore the previous behaviour.

Patch Changes

v3.17.1

Compare Source

Patch Changes

  • #​4474 382ef8f5 Thanks @​mrbbot! - fix: open browser to correct url pressing b in --remote mode

    This change ensures Wrangler doesn't try to open http://* when * is used as the dev server's hostname. Instead, Wrangler will now open http://127.0.0.1.

  • #​4488 3bd57238 Thanks @​RamIdeas! - Changes the default directory for log files to workaround frameworks that are watching the entire .wrangler directory in the project root for changes

    Also includes a fix for commands with --json where the log file location message would cause stdout to not be valid JSON. That message now goes to stderr.

v3.17.0

Compare Source

Minor Changes

  • #​4341 d9908743 Thanks @​RamIdeas! - Wrangler now writes all logs to a .log file in the .wrangler directory. Set a directory or specific .log filepath to write logs to with WRANGLER_LOG_PATH=../Desktop/my-logs/ or WRANGLER_LOG_PATH=../Desktop/my-logs/my-log-file.log. When specifying a directory or using the default location, a filename with a timestamp is used.

    Wrangler now filters workerd stdout/stderr and marks unactionable messages as debug logs. These debug logs are still observable in the debug log file but will no longer show in the terminal by default without the user setting the env var WRANGLER_LOG=debug.

Patch Changes
  • #​4469 d5e1966b Thanks @​mrbbot! - fix: report correct line and column numbers when source mapping errors with wrangler dev --remote

v3.16.0

Compare Source

Minor Changes
  • #​4347 102e15f9 Thanks @​Skye-31! - Feat(unstable_dev): Provide an option for unstable_dev to perform the check that prompts users to update wrangler, defaulting to false. This will prevent unstable_dev from sending a request to NPM on startup to determine whether it needs to be updated.

  • #​4179 dd270d00 Thanks @​matthewdavidrodgers! - Simplify secret:bulk api via script settings

    Firing PUTs to the secret api in parallel has never been a great solution - each request independently needs to lock the script, so running in parallel is at best just as bad as running serially.

    Luckily, we have the script settings PATCH api now, which can update the settings for a script (including secret bindings) at once, which means we don't need any parallelization. However this api doesn't work with a partial list of bindings, so we have to fetch the current bindings and merge in with the new secrets before PATCHing. We can however just omit the value of the binding (i.e. only provide the name and type) which instructs the config service to inherit the existing value, which simplifies this as well. Note that we don't use the bindings in your current wrangler.toml, as you could be in a draft state, and it makes sense as a user that a bulk secrets update won't update anything else. Instead, we use script settings api again to fetch the current state of your bindings.

    This simplified implementation means the operation can only fail or succeed, rather than succeeding in updating some secrets but failing for others. In order to not introduce breaking changes for logging output, the language around "${x} secrets were updated" or "${x} secrets failed" is kept, even if it doesn't make much sense anymore.

Patch Changes

  • #​4402 baa76e77 Thanks @​rozenmd! - This PR adds a fetch handler that uses page, assuming result_info provided by the endpoint contains page, per_page, and total

    This is needed as the existing fetchListResult handler for fetching potentially paginated results doesn't work for endpoints that don't implement cursor.

    Fixes #​4349

  • #​4337 6c8f41f8 Thanks @​Skye-31! - Improve the error message when a script isn't exported a Durable Object class

    Previously, wrangler would error with a message like Uncaught TypeError: Class extends value undefined is not a constructor or null. This improves that messaging to be more understandable to users.

  • #​4307 7fbe1937 Thanks @​jspspike! - Change local dev server default ip to * instead of 0.0.0.0. This will cause the dev server to listen on both ipv4 and ipv6 interfaces

v3.15.0

Compare Source

Minor Changes

  • #​4209 24d1c5cf Thanks @​mrbbot! - fix: suppress compatibility date fallback warnings if no wrangler update is available

    If a compatibility date greater than the installed version of workerd was
    configured, a warning would be logged. This warning was only actionable if a new
    version of wrangler was available. The intent here was to warn if a user set
    a new compatibility date, but forgot to update wrangler meaning changes
    enabled by the new date wouldn't take effect. This change hides the warning if
    no update is available.

    It also changes the default compatibility date for wrangler dev sessions
    without a configured compatibility date to the installed version of workerd.
    This previously defaulted to the current date, which may have been unsupported
    by the installed runtime.

  • #​4135 53218261 Thanks @​Cherry! - feat: resolve npm exports for file imports

    Previously, when using wasm (or other static files) from an npm package, you would have to import the file like so:

    import wasm from "../../node_modules/svg2png-wasm/svg2png_wasm_bg.wasm";

    This update now allows you to import the file like so, assuming it's exposed and available in the package's exports field:

    import wasm from "svg2png-wasm/svg2png_wasm_bg.wasm";

    This will look at the package's exports field in package.json and resolve the file using resolve.exports.

  • #​4232 69b43030 Thanks @​romeupalos! - fix: use zone_name to determine a zone when the pattern is a custom hostname

    In Cloudflare for SaaS, custom hostnames of third party domain owners can be used in Cloudflare.
    Workers are allowed to intercept these requests based on the routes configuration.
    Before this change, the same logic used by wrangler dev was used in wrangler deploy, which caused wrangler to fail with:

    ✘ [ERROR] Could not find zone for [partner-saas-domain.com]

  • #​4198 b404ab70 Thanks @​penalosa! - When uploading additional modules with your worker, Wrangler will now report the (uncompressed) size of each individual module, as well as the aggregate size of your Worker
Patch Changes

  • #​4274 be0c6283 Thanks @​jspspike! - chore: bump miniflare to 3.20231025.0

    This change enables Node-like console.log()ing in local mode. Objects with
    lots of properties, and instances of internal classes like Request, Headers,
    ReadableStream, etc will now be logged with much more detail.

  • #​4127 3d55f965 Thanks @​mrbbot! - fix: store temporary files in .wrangler

    As Wrangler builds your code, it writes intermediate files to a temporary
    directory that gets cleaned up on exit. Previously, Wrangler used the OS's
    default temporary directory. On Windows, this is usually on the C: drive.
    If your source code was on a different drive, our bundling tool would generate
    invalid source maps, breaking breakpoint debugging. This change ensures
    intermediate files are always written to the same drive as sources. It also
    ensures unused build outputs are cleaned up when running wrangler pages dev.

    This change also means you no longer need to set cwd and
    resolveSourceMapLocations in .vscode/launch.json when creating an attach
    configuration for breakpoint debugging. Your .vscode/launch.json should now
    look something like...

    {
	"configurations": [
		{
			"name": "Wrangler",
			"type": "node",
			"request": "attach",
			"port": 9229,
			// These can be omitted, but doing so causes silent errors in the runtime
			"attachExistingChildren": false,
			"autoAttachChildProcesses": false
		}
	]
}

  • #​4235 46cd2df5 Thanks @​mrbbot! - fix: ensure console.log()s during startup are displayed

    Previously, console.log() calls before the Workers runtime was ready to
    receive requests wouldn't be shown. This meant any logs in the global scope
    likely weren't visible. This change ensures startup logs are shown. In particular,
    this should fix Remix's HMR,
    which relies on startup logs to know when the Worker is ready.

v3.14.0

Compare Source

Minor Changes

  • #​2162 a1f212e6 Thanks @​WalshyDev! - add support for service bindings in wrangler pages dev by providing the
    new --service|-s flag which accepts an array of BINDING_NAME=SCRIPT_NAME
    where BINDING_NAME is the name of the binding and SCRIPT_NAME is the name
    of the worker (as defined in its wrangler.toml), such workers need to be
    running locally with with wrangler dev.

    For example if a user has a worker named worker-a, in order to locally bind
    to that they'll need to open two different terminals, in each navigate to the
    respective worker/pages application and then run respectively wrangler dev and
    wrangler pages ./publicDir --service MY_SERVICE=worker-a this will add the
    MY_SERVICE binding to pages' worker env object.

    Note: additionally after the SCRIPT_NAME the name of an environment can be specified,
    prefixed by an @ (as in: MY_SERVICE=SCRIPT_NAME@PRODUCTION), this behavior is however
    experimental and not fully properly defined.

v3.13.2

Compare Source

Patch Changes

v3.13.1

Compare Source

Patch Changes
  • #​4171 88f15f61 Thanks @​penalosa! - patch: This release fixes some regressions related to running wrangler dev that were caused by internal refactoring of the dev server architecture (#​3960). The change has been reverted, and will be added back in a future release.

v3.13.0

Compare Source

Minor Changes

  • #​3960 c36b78b4 Thanks @​RamIdeas! - Refactoring the internals of wrangler dev servers (including wrangler dev, wrangler dev --remote and unstable_dev()).

    There are no changes required for developers to opt-in. Improvements include:

    • fewer 'address in use' errors upon reloads
    • upon config/source file changes, requests are buffered to guarantee the response is from the new version of the Worker
Patch Changes
  • #​3590 f4ad634a Thanks @​penalosa! - fix: When a middleware is configured which doesn't support your Worker's script format, fail early with a helpful error message

v3.12.0

Compare Source

Minor Changes

  • #​4071 f880a009 Thanks @​matthewdavidrodgers! - Support TailEvent messages in Tail sessions

    When tailing a tail worker, messages previously had a null event property. Following https://github.com/cloudflare/workerd/pull/1248, these events have a valid event, specifying which scripts produced events that caused your tail worker to run.

    As part of rolling this out, we're filtering out tail events in the internal tail infrastructure, so we control when these new messages are forward to tail sessions, and can merge this freely.

    One idiosyncracy to note, however, is that tail workers always report an "OK" status, even if they run out of memory or throw. That is being tracked and worked on separately.

  • #​2397 93833f04 Thanks @​a-robinson! - feature: Support Queue consumer events in tail

    So that it's less confusing when tailing a worker that consumes events from a Queue.

Patch Changes

  • #​2687 3077016f Thanks @​jrf0110! - Fixes large Pages projects failing to complete direct upload due to expiring JWTs

    For projects which are slow to upload - either because of client bandwidth or large numbers of files and sizes - It's possible for the JWT to expire multiple times. Since our network request concurrency is set to 3, it's possible that each time the JWT expires we get 3 failed attempts. This can quickly exhaust our upload attempt count and cause the entire process to bail.

    This change makes it such that jwt refreshes do not count as a failed upload attempt.

v3.11.0

Compare Source

Minor Changes

  • #​3726 7d20bdbd Thanks @​petebacondarwin! - feat: support partial bundling with configurable external modules

    Setting find_additional_modules to true in your configuration file will now instruct Wrangler to look for files in
    your base_dir that match your configured rules, and deploy them as unbundled, external modules with your Worker.
    base_dir defaults to the directory containing your main entrypoint.

    Wrangler can operate in two modes: the default bundling mode and --no-bundle mode. In bundling mode, dynamic imports
    (e.g. await import("./large-dep.mjs")) would be bundled into your entrypoint, making lazy loading less effective.
    Additionally, variable dynamic imports (e.g. await import(`./lang/${language}.mjs`)) would always fail at runtime,
    as Wrangler would have no way of knowing which modules to upload. The --no-bundle mode sought to address these issues
    by disabling Wrangler's bundling entirely, and just deploying code as is. Unfortunately, this also disabled Wrangler's
    code transformations (e.g. TypeScript compilation, --assets, --test-scheduled, etc).

    With this change, we now additionally support partial bundling. Files are bundled into a single Worker entry-point file
    unless find_additional_modules is true, and the file matches one of the configured rules. See
    https://developers.cloudflare.com/workers/wrangler/bundling/ for more details and examples.

Patch Changes

  • #​3726 7d20bdbd Thanks @​petebacondarwin! - fix: ensure that additional modules appear in the out-dir

    When using find_additional_modules (or no_bundle) we find files that
    will be uploaded to be deployed alongside the Worker.

    Previously, if an outDir was specified, only the Worker code was output
    to this directory. Now all additional modules are also output there too.

  • #​4067 31270711 Thanks @​mrbbot! - fix: generate valid source maps with wrangler pages dev on macOS

    On macOS, wrangler pages dev previously generated source maps with an
    incorrect number of ../s in relative paths. This change ensures paths are
    always correct, improving support for breakpoint debugging.

  • #​3726 7d20bdbd Thanks @​petebacondarwin! - fix: allow __STATIC_CONTENT_MANIFEST module to be imported anywhere

    __STATIC_CONTENT_MANIFEST can now be imported in subdirectories when
    --no-bundle or find_additional_modules are enabled.

  • #​4066 c8b4a07f Thanks @​RamIdeas! - fix: we no longer infer pathnames from route patterns as the host

    During local development, inside your worker, the host of request.url is inferred from the routes in your config.

    Previously, route patterns like "*/some/path/name" would infer the host as "some". We now handle this case and determine we cannot infer a host from such patterns.

v3.10.1

Compare Source

Patch Changes
  • #​4041 6b1c327d Thanks @​elithrar! - Fixed a bug in Vectorize that send preset configurations with the wrong key. This was patched on the server-side to work around this for users in the meantime.

  • #​4054 f8c52b93 Thanks @​mrbbot! - fix: allow wrangler pages dev sessions to be reloaded

    Previously, wrangler pages dev attempted to send messages on a closed IPC
    channel when sources changed, resulting in an ERR_IPC_CHANNEL_CLOSED error.
    This change ensures the channel stays open until the user exits wrangler pages dev.

v3.10.0

Compare Source

Minor Changes
Patch Changes
  • #​4034 bde9d64a Thanks @​ndisidore! - Adds Vectorize support uploading batches of newline delimited json (ndjson)
    vectors from a source file.
    Load a dataset with vectorize insert my-index --file vectors.ndjson

v3.9.1

Compare Source

Patch Changes

  • #​3992 35564741 Thanks @​edevil! - Add AI binding that will be used to interact with the AI project.

    Example wrangler.toml

    name = "ai-worker"
main = "src/index.ts"

[ai]
binding = "AI"

    Example script:

    import Ai from "@​cloudflare/ai"

export default {
    async fetch(request: Request, env: Env): Promise<Response> {
        const ai = new Ai(env.AI);

        const story = await ai.run({
            model: 'llama-2',
            input: {
                prompt: 'Tell me a story about the future of the Cloudflare dev platform'
            }
        });

    return new Response(JSON.stringify(story));
    },
};

export interface Env {
    AI: any;
}
  • #​4006 bc8c147a Thanks @​rozenmd! - fix: remove warning around using D1's binding, and clean up the epilogue when running D1 commands

v3.9.0

Compare Source

Minor Changes

  • #​3951 e0850ad1 Thanks @​mrbbot! - feat: add support for breakpoint debugging to wrangler dev's --remote and --no-bundle modes

    Previously, breakpoint debugging using Wrangler's DevTools was only supported
    in local mode, when using Wrangler's built-in bundler. This change extends that
    to remote development, and --no-bundle.

    When using --remote and --no-bundle together, uncaught errors will now be
    source-mapped when logged too.

  • #​3951 e0850ad1 Thanks @​mrbbot! - feat: add support for Visual Studio Code's built-in breakpoint debugger

    Wrangler now supports breakpoint debugging with Visual Studio Code's debugger.
    Create a .vscode/launch.json file with the following contents...

    {
	"configurations": [
		{
			"name": "Wrangler",
			"type": "node",
			"request": "attach",
			"port": 9229,
			"cwd": "/",
			"resolveSourceMapLocations": null,
			"attachExistingChildren": false,
			"autoAttachChildProcesses": false
		}
	]
}

    ...then run wrangler dev, and launch the configuration.

Patch Changes

  • #​3928 95b24b1e Thanks @​JacobMGEvans! - Colorize Deployed Bundle Size
    Most bundlers, and other tooling that give you size outputs will colorize their the text to indicate if the value is within certain ranges.
    The current range values are:
    red 100% - 90%
    yellow 89% - 70%
    green <70%

    resolves #​1312

v3.8.0

Compare Source

Minor Changes

  • #​3775 3af30879 Thanks @​bthwaites! - R2 Jurisdictional Restrictions guarantee objects in a bucket are stored within a specific jurisdiction. Wrangler now allows you to interact with buckets in a defined jurisdiction.

    Wrangler R2 operations now support a -J flag that allows the user to specify a jurisdiction. When passing the -J flag, you will only be able to interact with R2 resources within that jurisdiction.

    

    • 



v3.7.0


Compare Source


Minor Changes






    

  • 

    #​3774 ae2d5cb5 Thanks @​mrbbot! - feat: support breakpoint debugging in local mode
    

    wrangler dev now supports breakpoint debugging in local mode! Press d to open DevTools and set breakpoints.
    

    • 



v3.6.0


Compare Source


Minor Changes



Patch Changes




    

  • 

    #​3758 0adccc71 Thanks @​jahands! - fix: Retry deployment errors in wrangler pages publish
    

    This will improve reliability when deploying to Cloudflare Pages
    

    • 



v3.5.1


Compare Source


Patch Changes





v3.5.0


Compare Source


Minor Changes




    

  • #​3704 8e231afd Thanks @​JacobMGEvans! - secret:bulk exit 1 on failure
    
Previously secret"bulk would only log an error on failure of any of the upload requests.
    
Now when 'secret:bulk' has an upload request fail it throws an Error which sends an process.exit(1) at the root .catch() signal.
    
This will enable error handling in programmatic uses of secret:bulk.
    • 






    

  • #​3595 c302bec6 Thanks @​geelen! - Removing the D1 shim from the build process, in preparation for the Open Beta. D1 can now be used with --no-bundle enabled.
    • 





Patch Changes



v3.4.0


Compare Source


Minor Changes


    

  • 

    #​3649 e2234bbc Thanks @​JacobMGEvans! - Feature: 'stdin' support for 'secret:bulk'
    
Added functionality that allows for files and strings to be piped in, or other means of standard input. This will allow for a broader variety of use cases and improved DX.
    
This implementation is also fully backward compatible with the previous input method of file path to JSON.
    

    

    • 



v3.3.0


Compare Source


Minor Changes



Patch Changes


    

  • 

    #​3587 30f114af Thanks @​mrbbot! - fix: keep configuration watcher alive
    

    Ensure wrangler dev watches the wrangler.toml file and reloads the server whenever configuration (e.g. KV namespaces, compatibility dates, etc) changes.
    

    • 





v3.2.0


Compare Source


Minor Changes




    

  • 

    #​3426 5a74cb55 Thanks @​matthewdavidrodgers! - Prefer non-force deletes unless a Worker is a dependency of another.
    

    If a Worker is used as a service binding, a durable object namespace, an outbounds for a dynamic dispatch namespace, or a tail consumer, then deleting that Worker will break those existing ones that depend upon it. Deleting with ?force=true allows you to delete anyway, which is currently the default in Wrangler.
    

    Force deletes are not often necessary, however, and using it as the default has unfortunate consequences in the API. To avoid them, we check if any of those conditions exist, and present the information to the user. If they explicitly acknowledge they're ok with breaking their other Workers, fine, we let them do it. Otherwise, we'll always use the much safer non-force deletes. We also add a "--force" flag to the delete command to skip the checks and confirmation and proceed with ?force=true
    

    • 



Patch Changes


    

  • 

    #​3585 e33bb44a Thanks @​mrbbot! - fix: register middleware once for module workers
    

    Ensure middleware is only registered on the first request when using module workers.
    
This should prevent stack overflows and slowdowns when making large number of requests to wrangler dev with infrequent reloads.
    

    • 




    

  • #​3547 e16d0272 Thanks @​jspspike! - Fixed issue with wrangler dev not finding imported files. Previously when wrangler dev would automatically reload on any file changes, it would fail to find any imported files.
    • 



v3.1.2


Compare Source


Patch Changes






    

  • #​3497 c5f3bf45 Thanks @​evanderkoogh! - Refactor dev-only checkedFetch check from a method substitution to a JavaScript Proxy to be able to support Proxied global fetch function.
    • 




    

  • [#​3403](https:
    • 







Configuration


📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).


🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.


♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.


🔕 Ignore: Close this PR and you won't be reminded about this update again.




    

  •  If you want to rebase/retry this PR, check this box
    • 





This PR has been generated by Mend Renovate. View repository job log here.


    

  
  



      


          

          
  

    
  
  

  

  




          

        
      




  





      

       
            



      

  
        





      

  
          

  
  

  
      @renovate
  renovate
bot

        force-pushed
    the
        
      
  renovate/npm-wrangler-vulnerability


    
 branch
    from
    
      b1d03a2
    to
    
      c789e61
      
    Compare
  



    
      March 31, 2024 12:55
    
    









      

  
      



  

  @changeset-bot

    
      changeset-bot
    




  


    

      

  

    

        
    
    

  


      
          
  
      
            Copy link

  

      
    

  


  

      

      



      

  


  

    

      

      
          changeset-bot
  bot

      

      

      commented


        Mar 31, 2024


      
    


  





      


        


  
    

      
          
⚠️  No Changeset found


Latest commit: c789e61


Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.


Click here to learn what changesets are, and how to add one.


Click here if you're a maintainer who wants to add a changeset to this PR

      		
    

  





        


            

              
            

        

      


      

            
  

    
  
  

  

  



    
















  
  

    

      

  




    


    

      

              

  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment


  



      

    

  




  
          




      

  

    

    
  

    Reviewers
  


    

    No reviews






    

  


      
  

    Assignees
  



        

    No one assigned







      


  


  

    Labels
  



    

    None yet







      

  

    

        

    Projects
  


        




    None yet




  



      

  

    
  

    Milestone
  


      No milestone





    
      
          


  

    
      

        
    

    Development
  



          



Successfully merging this pull request may close these issues.


  
    
None yet

  




    
  




        
      

    

  
      

  

    

      0 participants