chore: package @packages/network as an independent bundle

[AtofStryker]

• Closes N/A

Additional details

This PR refactors @packages/network into two packages, @packages/network and @packages/network-tools.

Why are we doing this?

The refactor was prompted by the effort to make every package an independent bundle, where packages are built themselves and needed functions/modules are imported through the main package entrypoint and not importing the source directly. This means that:

import { module } from '@packages/network/path/to/not/transpiled/code' 

and would need to do

import { module }  from '@packages/network' 

Will no longer work as the the the source files are not compiled along side the module and are not shipped with the module. It may work in the monorepo, but it will FAIL when you attempt to build the binary. This means that the function needs to be imported from the package directly and not from a source file

This will change over time as we are able to update our TypeScript targets, but currently because we are bound to moduleResolution:'node', we can't leverage export paths, similar to how we do in the CLI. Eventually, when our internal packages are ESM-only, this type of pattern will be much less of a concern, but until we get there we need to adhere to this type of compiling/module building.

As a positive side effect, it makes individually type checking individual packages much easier as we can ship declaration types with the package, which is much better respected by skipLibCheck in the tsconfig.json vs importing directly from source, which means the package importing from another module has to completely TypeCheck the other module.

Right now, as we are in a grey area between sinon/mocha/chai and vitest, importing from src is usally fine in a testing context because the files are present. They are also much easier to mock in sinon then from a distributed package because sinon can't mock ES6 classes effectively. The only mechanism to do this is to stub the prototype, which is not ideal.

The new structure

@packages/network-tools only contains the cors, uri, and document domain utilities that are used commonly throughout the repo. This will likely include some of the cookie utils that are used in the server in the future to avoid circular dependencies between a given package and the server

@packages/network-tools only contains utilities and can run in either the browser OR the node context. @packages/network as a true distributed package contains a lot of node code, which means it can't run in the browser unless we polyfill the libraries needed or change them. The frontend modules only need the non-node utilities, hence the refactor.

With the refactor, I tried to remove bluebird references where possible and use async/await. Now that the types of changed for how the package is built, I needed to fix/add types in some areas. A couple types are failing in the server in the v8-snapshot task and to be honest, why that is currently is not clear to me, so those are handled with a ts-ignore.

Steps to test

How has the user experience changed?

PR Tasks

• Have tests been added/updated?
• Has a PR for user-facing changes been opened in cypress-documentation?
• Have API changes been updated in the type definitions?

---

Note

Extracts shared CORS/URI/document-domain utilities into new @packages/network-tools, modernizes @packages/network (builds/types, async/await), and updates imports, tests, and CI workflows accordingly.

• Packages:
  • New: @packages/network-tools exporting cors, uri, document-domain-injection, and related types for browser/Node usage.
  • @packages/network: Now Node-only; adds CJS/ESM builds, strictAgent/CombinedAgent exports from package root; removes runtime ts-register entry; updates package/build configs.
• Refactors:
  • Replace direct @packages/network/lib/* imports with @packages/network-tools (driver, proxy, server, config, tests).
  • Migrate several modules from Bluebird to native async/await (e.g., lib/agent.ts, lib/connect.ts, test servers). Tighten typings and null checks.
  • Adjust APIs moved to network-tools (e.g., policyFromConfig, origin, URL/domain helpers).
  • Convert several server/cloud files from CJS to ESM-style imports and fix types.
• CI:
  • Swap build steps order and require build before packaging; update arm64 workflows; bump cache version.
• Docs/Guides/Tests:
  • Update ESM migration guide statuses (network/network-tools complete).
  • Add tests for @packages/network-tools and update existing tests to new imports.

^{Written by Cursor Bugbot for commit 33afff1. This will update automatically on new commits. Configure here.}

[cypress]

cypress    Run #66368

Run Properties:   Failed #66368  •  33afff1783: update pull-request job as well

Project	cypress
Branch Review	chore/network-bundle
Run status	Failed #66368
Run duration	16m 31s
Commit	33afff1783: update pull-request job as well
Committer	Bill Glesias
View all properties for this run ↗︎

---

Test results
Failures	1
Flaky	1
Pending	11
Skipped	0
Passing	631
View all changes introduced in this branch ↗︎

UI Coverage  0%
Untested elements	4
Tested elements	0

Accessibility  100%
Failed rules	0 critical   0 serious   0 moderate   0 minor
Failed elements	0

---

Tests for review

  cypress/e2e/studio/studio.cy.ts • 1 failed test • app-e2e

View Output

Test		Artifacts
Cypress Studio > updates an existing test with assertions		Test Replay Screenshots

  cypress/e2e/specs.cy.ts • 1 flaky test • app-e2e

View Output

Test		Artifacts
... > create template spec > shows dialog that can be dismissed with Close (x) button press		Test Replay Screenshots