# @fluidframework/shared-object-base

## 3.6.0

Dependency updates only.

## 3.5.0

Dependency updates only.

## 3.4.0

Dependency updates only.

## 3.3.0

Dependency updates only.

## 3.2.0

Dependency updates only.

## 3.1.0

Dependency updates only.

## 3.0.0

### Minor Changes

- Removal of direct CommonJS support ([#28124](https://github.com/microsoft/FluidFramework/pull/28124)) [0f84e3b8878](https://github.com/microsoft/FluidFramework/commit/0f84e3b8878a5e75b2253976d98fd963bbd9db88)

  Direct `require()` import is no longer directly supported.
  Package is transpiled as ECMAScript Module.

  See [Removal of direct CommonJS support in v3.0](https://github.com/microsoft/FluidFramework/issues/27444) for more information.

- Require modern TypeScript module resolution ([#27970](https://github.com/microsoft/FluidFramework/pull/27970)) [325e2016ca9](https://github.com/microsoft/FluidFramework/commit/325e2016ca9978d4a1f7552c97ba34feac9df41f)

  Fluid Framework Client packages no longer include type declaration compatibility entrypoints for TypeScript's legacy Node10 resolution mode (`"moduleResolution": "node"` or `"node10"`).
  Applications upgrading to Fluid Framework 3.0 must use one of the following supported configurations:
  - `"module": "Node16"` with `"moduleResolution": "Node16"`
  - `"module": "NodeNext"` with `"moduleResolution": "NodeNext"`
  - `"module": "ESNext"` with `"moduleResolution": "Bundler"`

  Existing public package entrypoints exposed through `package.json` exports, including `/alpha`, `/beta`, and `/legacy`, remain available under supported module resolution modes.

  See [Removal of Node10 resolutions in v3.0](https://github.com/microsoft/FluidFramework/issues/27457) for more information.

- Client packages now target ES2022 ([#27846](https://github.com/microsoft/FluidFramework/pull/27846)) [91c78541bdd](https://github.com/microsoft/FluidFramework/commit/91c78541bddcbca5d6c5f357b023eeaee617d885)

  The TypeScript compilation `target` and `lib` for the Fluid Framework client packages have been raised from ES2021/ES2020 to **ES2022**.
  The published JavaScript now uses ES2022 language features (with correspondingly less down-leveling), so consuming these packages requires a runtime that supports ES2022.
  All actively supported Node.js versions and evergreen browsers already meet this requirement.

  Note that Fluid Framework has not officially supported targets older than ES2022 since before 2.0: this is documented in [ClientRequirements.md](https://github.com/microsoft/FluidFramework/blob/main/ClientRequirements.md) as well as the README for every client package.

  It is possible this change could impact users of less up to date JavaScript runtimes.
  Impacted users can use a tool like [babel](https://babeljs.io/) to transpile out unsupported language features.

- Build with TypeScript 6 ([#28052](https://github.com/microsoft/FluidFramework/pull/28052)) [7ab015c49de](https://github.com/microsoft/FluidFramework/commit/7ab015c49deec84833cdfe1fb5e1606b901f6e81)

  FluidFramework Client SDK is now built using TypeScript 6. Consumers should build with TypeScript v6 or v7 or compatible tooling.

## 2.116.0

Dependency updates only.

## 2.115.0

Dependency updates only.

## 2.114.0

### Minor Changes

- Add new @alpha ServiceClient API for creating and loading Fluid containers ([#27693](https://github.com/microsoft/FluidFramework/pull/27693)) [ee47192d4a](https://github.com/microsoft/FluidFramework/commit/ee47192d4ae91bc28f9154c4d1ead2acad762f3c)

  This introduces an experimental (`@alpha`), service-agnostic API for working with Fluid containers whose root is an arbitrary data store, along with an in-memory implementation for testing.

  The new surface is made up of:
  - `ServiceClient` (`@fluidframework/driver-definitions`): the entry point for creating and loading containers. Along with it come the supporting container types (`FluidContainer`, `FluidContainerWithService`, `FluidContainerAttached`), the data store model (`DataStoreKind`, `DataStoreKey`, `DataStoreRegistry`, `DataStoreCreator`), and the generic registry primitives (`Registry`, `RegistryKey`, `lookupInRegistry`, `createBasicRegistryKey`).
  - `defineDataStore` and `sharedObjectRegistryFromIterable` (`@fluidframework/shared-object-base`): build a `DataStoreKind` from a root shared object and a registry of shared object kinds.
  - `defineTreeDataStore` and `instantiateTreeFirstTime` (`@fluidframework/tree`): a SharedTree-specific convenience wrapper that produces a `DataStoreKind` backed by a `TreeView`.
  - `startEphemeralService` (`@fluidframework/local-driver`): starts an in-memory `EphemeralService` for tests. The service owns the lifetime of the in-memory documents and resources, and produces `ServiceClient`s connected to it (via `EphemeralService.newClient` or `EphemeralService.defaultClient`). The helpers `cleanupEphemeralService` and `getDefaultEphemeralService` manage an optional default service instance.

  Apart from the `@fluidframework/local-driver` helpers (which come from `@fluidframework/local-driver/alpha`), these APIs are also re-exported from `fluid-framework`. None reference any `@legacy` types.

  Example:

  ```typescript
  import { startEphemeralService } from "@fluidframework/local-driver/alpha";
  import {
    ServiceClient,
    defineTreeDataStore,
    TreeViewConfiguration,
    SchemaFactory,
  } from "fluid-framework/alpha";
  import { strict as assert } from "node:assert";

  // Start an ephemeral in-memory service and get a ServiceClient connected to it.
  const service = startEphemeralService();
  const client: ServiceClient = service.defaultClient;
  // Define a DataStoreKind which uses a SharedTree.
  // In this case the schema is for a single number with an initializer that starts the it at 1.
  // This schema is captures in the type allowing for strongly typed access to the data in the tree,
  // where the type matches the schema based runtime enforcement of the schema.
  const numberStore = defineTreeDataStore({
    type: "my-app-root",
    config: new TreeViewConfiguration({ schema: SchemaFactory.number }),
    initializer: () => 1,
  });

  // Create a container in the service with the above DataStoreKind.
  // Ideally this creation would use a service independent API, and only the attach call would be service dependent,
  // but that is not supported yet.
  const detachedContainer1 = await client.createContainer(numberStore);
  const container1 = await detachedContainer1.attach();

  // We now have easy and type safe access to the data in the tree, which will be synced over the service.
  assert.equal(container1.data.root, 1);

  // A second client can load the same container from the service, and will see the same data.
  const container2 = await client.loadContainer(container1.id, numberStore);
  assert.equal(container2.data.root, 1);

  // Both clients can modify the data, and the changes will be synced over the service.
  container2.data.root = 2;
  // Since we are using an ephemeral service, we can await the synchronization using service.synchronize.
  await service.synchronize();

  // And now the changes are visible for all clients.
  assert.equal(container1.data.root, 2);
  assert.equal(container2.data.root, 2);
  ```

  Note that this example does a couple of things which are difficult to do with the other API surfaces:
  1. It creates a container, then loads a second copy of it, allowing for collaboration. There is currently no non-legacy API surface which allows this without spawning a server process. This is also cleaner than the exacting legacy API options, and can replace the test specific APIs for this as well.
  2. It creates a container which has a SharedTree at the root, and nothing else. This avoids depending on legacy DDS implementations, which is great for long-term document support and bundle size. This is currently impossible using `fluid-static`, which forces a special root data store. It is also impossible if using `aqueduct`, which forces a root directory in every data store. It can be done using the low level legacy APIs directly, but this new API for it is much simpler.
  3. There is a common interface all services implement (`ServiceClient`), making the container creation part of the code work for any service implementation.

## 2.113.0

Dependency updates only.

## 2.112.0

Dependency updates only.

## 2.111.0

Dependency updates only.

## 2.110.0

Dependency updates only.

## 2.103.0

Dependency updates only.

## 2.102.0

Dependency updates only.

## 2.101.0

Dependency updates only.

## 2.100.0

### Minor Changes

- Node 22 is now the minimum supported Node.js version ([#27116](https://github.com/microsoft/FluidFramework/pull/27116)) [e8214d29663](https://github.com/microsoft/FluidFramework/commit/e8214d29663f5ee98d737daed82506a25d8de8d0)

  All Fluid Framework client packages now require Node.js 22 or later. This aligns with the standing Node upgrade policy as Node 20 reaches end-of-life on April 30, 2026.

## 2.93.0

### Minor Changes

- minVersionForCollab is now non-optional ([#25331](https://github.com/microsoft/FluidFramework/pull/25331)) [9a0d0272df](https://github.com/microsoft/FluidFramework/commit/9a0d0272df6ae1a521cff00292dd159ea3b5e270)

  This change is a follow-up for [pull request 25130](https://github.com/microsoft/FluidFramework/pull/25130)
  which was released as part of [2.61.0](https://github.com/microsoft/FluidFramework/releases/tag/client_v2.61.0).

  The `minVersionForCollab` property has been made non-optional in the following `@beta` `@legacy` interfaces in the Runtime layer:
  - `IFluidParentContext.minVersionForCollab` in `@fluidframework/runtime-definitions`.
  - `IFluidDataStoreContext.minVersionForCollab` in `@fluidframework/runtime-definitions`.
  - `IFluidDataStoreContextDetached.minVersionForCollab` in `@fluidframework/runtime-definitions`.

  Consumers of Fluid aren't expected to implement these interfaces directly, so no impact is expected.

  Additionally the following properties now always return a value, rather than possibly returning `undefined`:
  - `FluidDataStoreRuntime.minVersionForCollab` in `@fluidframework/datastore`.
    Note that API Extractor shows this as a breaking change since FluidDataStoreRuntime is beta + legacy and non-sealed.
    However, FluidDataStoreRuntime is not intended to be extended directly outside of a known legacy use-case.
  - `IDataObjectProps.context.minVersionForCollab` in `@fluidframework/aqueduct`.
  - `ITestFluidObject.context.minVersionForCollab` in `@fluidframework/test-utils`
  - `IProvideTestFluidObject.ITestFluidObject.context.minVersionForCollab` in `@fluidframework/test-utils`

## 2.92.0

Dependency updates only.

## 2.91.0

Dependency updates only.

## 2.90.0

Dependency updates only.

## 2.83.0

Dependency updates only.

## 2.82.0

Dependency updates only.

## 2.81.0

Dependency updates only.

## 2.80.0

Dependency updates only.

## 2.74.0

Dependency updates only.

## 2.73.0

Dependency updates only.

## 2.72.0

Dependency updates only.

## 2.71.0

Dependency updates only.

## 2.70.0

### Minor Changes

- Deprecated property processCore has been removed from SharedObject ([#25749](https://github.com/microsoft/FluidFramework/pull/25749)) [a33a2e370f](https://github.com/microsoft/FluidFramework/commit/a33a2e370fbb95b565f39c2a14abc7716bc01980)

  The deprecated property `processCore` has been removed from `SharedObject`.

  Please see [this github issue](https://github.com/microsoft/FluidFramework/issues/25176) for more details.

## 2.63.0

Dependency updates only.

## 2.62.0

Dependency updates only.

## 2.61.0

Dependency updates only.

## 2.60.0

Dependency updates only.

## 2.53.0

Dependency updates only.

## 2.52.0

Dependency updates only.

## 2.51.0

Dependency updates only.

## 2.50.0

Dependency updates only.

## 2.43.0

### Minor Changes

- Added an optional boolean parameter "fullTree" to SharedObject's summarizeCore method ([#24761](https://github.com/microsoft/FluidFramework/pull/24761)) [1e24967a8f9](https://github.com/microsoft/FluidFramework/commit/1e24967a8f943b0616d765c253fe079fc9c43619)

  This parameter tells the shared object that it should generate a full tree summary, i.e., it must not summarize incrementally.
  Currently no known `SharedObject`'s do incremental summaries; however, any that do exist or are made in the future must take this "fullTree" parameter into consideration to function correctly.

## 2.42.0

Dependency updates only.

## 2.41.0

Dependency updates only.

## 2.40.0

### Minor Changes

- IFluidHandleInternal.bind has been deprecated ([#24553](https://github.com/microsoft/FluidFramework/pull/24553)) [8a4362a7ed](https://github.com/microsoft/FluidFramework/commit/8a4362a7edef3a97fee13c9d23bea49448ba2a6a)

  Handle binding is an internal concept used to make sure objects attach to the Container graph when their handle is stored in a DDS which is itself attached.
  The source of the "bind" operation has been assumed to be any handle, but only one implementation is actually supported (`SharedObjectHandle`, not exported itself).

  So the `bind` function is now deprecated on the `IFluidHandleInterface`, moving instead to internal types supporting the one valid implementation.
  It's also deprecated on the various exported handle implementations that don't support it (each is either no-op, pass-through, or throwing).

  No replacement is offered, this API was never meant to be called from outside of the Fluid Framework.

## 2.33.0

Dependency updates only.

## 2.32.0

Dependency updates only.

## 2.31.0

Dependency updates only.

## 2.30.0

Dependency updates only.

## 2.23.0

Dependency updates only.

## 2.22.0

### Minor Changes

- Change when the `pre-op` and `op` events on `ISharedObjectEvents` are emitted ([#23836](https://github.com/microsoft/FluidFramework/pull/23836)) [5eb19a0fc6](https://github.com/microsoft/FluidFramework/commit/5eb19a0fc6f00ba47ddc338a1a5932e683a6039c)

  Previous behavior - `pre-op` was emitted immediately before an op was processed. Then the op was processed and `op` was emitted immediately after that.

  New behavior - `pre-op` will still be emitted before an op is processed and `op` will still be emitted after an op is processed. However, these won't be immediate and other ops in a batch for the shared object may be processed in between.

  Note that these events are for internal use only as mentioned in the @remarks section of their definition.

- Deprecate `processCore` on `SharedObject` and `SharedObjectCore` in favor of `processMessagesCore` ([#23836](https://github.com/microsoft/FluidFramework/pull/23836)) [5eb19a0fc6](https://github.com/microsoft/FluidFramework/commit/5eb19a0fc6f00ba47ddc338a1a5932e683a6039c)

  A new function `processMessagesCore` has been added in place of `processCore`, which will be called to process multiple messages instead of a single one on the channel. This is part of a feature called "Op bunching" where contiguous ops in a grouped batch are bunched and processed together by the shared object.

  Implementations of `SharedObject` and `SharedObjectCore` must now also implement `processMessagesCore`. A basic implementation could be to iterate over the messages' content and process them one by one as it happens now. Note that some DDS may be able to optimize processing by processing the messages together.

## 2.21.0

Dependency updates only.

## 2.20.0

### Minor Changes

- Replace 'any' in return type for several APIs ([#23238](https://github.com/microsoft/FluidFramework/pull/23238)) [0783a31731](https://github.com/microsoft/FluidFramework/commit/0783a317317647e8881ec717a6f85c531cdbc956)

  To improve type safety of the Fluid Framework legacy+alpha API surface,
  we're moving away from using the `any` type in favor of `unknown`.

  We expect that any changes required in consumers of these APIs will be limited to having to provide explicit types
  when calling any of the APIs whose return value changed to `unknown`, like `IFluidSerializer.parse()`.

  In summary, code that looked like this:

  ```typescript
  // 'myVariable' ended up typed as 'any' here and TypeScript would not do any type-safety checks on it.
  const myVariable = this.serializer.parse(stringHeader);
  ```

  Will now have to look like this:

  ```typescript
  // Do this if you know the type of the object you expect to get back.
  const myVariable = this.serializer.parse(stringHeader) as MyType;

  // Alternatively, this will maintain current behavior but also means no type-safety checks will be done by TS.
  // const myVariable = this.serializer.parse(stringHeader) as any;
  ```

  The appropriate type will depend on what the calling code is doing and the objects it expects to be dealing with.

  We further encourage consumers of any of these APIs to add runtime checks
  to validate that the returned object actually matches the expected type.

  The list of affected APIs is as follows:
  - `IFluidSerializer.encode(...)` now takes `value: unknown` instead of `value: any` and returns `unknown` instead of `any`.
  - `IFluidSerializer.decode(...)` now takes `input: unknown` instead of `input: any` and returns `unknown` instead of `any`.
  - `IFluidSerializer.stringify(...)` now takes `value: unknown` instead of `value: any`.
  - `IFluidSerializer.parse(...)` now returns `unknown` instead of `any`.
  - `SharedObjectCore.applyStashedOps(...)` now takes `content: unknown` instead of `content: any`.
  - `SharedObjectCore.rollback(...)` now takes `content: unknown` instead of `content: any`.
  - `SharedObjectCore.submitLocalMessage(...)` now takes `content: unknown` instead of `content: any`.
  - `SharedObjectCore.reSubmitCore(...)` now takes `content: unknown` instead of `content: any`.
  - In `SharedObjectCore.newAckBasedPromise<T>(...)` the `executor` parameter now takes `reject: (reason?: unknown)`
    instead of `reject: (reason?: any)`.
  - `makeHandlesSerializable(...)` now returns `unknown` instead of `any`.
  - `parseHandles(...)` now returns `unknown` instead of `any`.

  Additionally, the following APIs were never designed to return a value and have thus been updated to return `void` instead of `any`:
  - `SharedObjectCore.processCore(...)`.
  - `SharedObjectCore.onDisconnect(...)`

## 2.13.0

Dependency updates only.

## 2.12.0

Dependency updates only.

## 2.11.0

Dependency updates only.

## 2.10.0

Dependency updates only.

## 2.5.0

Dependency updates only.

## 2.4.0

Dependency updates only.

## 2.3.0

Dependency updates only.

## 2.2.0

Dependency updates only.

## 2.1.0

### Minor Changes

- Type guards for DDS types ([#21850](https://github.com/microsoft/FluidFramework/pull/21850)) [6bdec1ac07](https://github.com/microsoft/FluidFramework/commit/6bdec1ac07d6f95ef2fbcbd66c12bf0dc53de1ad)

  In the 2.0 release of Fluid, the concrete class implementations for DDSes were hidden from Fluid's API surface.
  This made `instanceof` checks fail to work correctly.
  There were ways to work around this in application code, but they involved boilerplate which required more understanding of Fluid internals than should be necessary.

  There is now a drop-in replacement to `instanceof`: the static `.is()` method to `SharedObjectKind`, which is available
  on all DDSes.
  For example:

  ```typescript
  // Works in Fluid Framework 1.0 but not in the initial release of Fluid Framework 2.0:
  if (myObject instanceof SharedString) {
    // do something
  }

  // In Fluid Framework 2.0 and beyond, that code can now be written like so:
  if (SharedString.is(myObject)) {
    // do something
  }
  ```

## 2.0.0-rc.5.0.0

### Minor Changes

- fluid-framework: Type Erase ISharedObjectKind ([#21081](https://github.com/microsoft/FluidFramework/pull/21081)) [78f228e370](https://github.com/microsoft/FluidFramework/commit/78f228e37055bd4d9a8f02b3a1eefebf4da9c59c)

  A new type, `SharedObjectKind` is added as a type erased version of `ISharedObjectKind` and `DataObjectClass`.

  This type fills the role of both `ISharedObjectKind` and `DataObjectClass` in the `@public` "declarative API" exposed in the `fluid-framework` package.

  This allows several types referenced by `ISharedObjectKind` to be made `@alpha` as they should only need to be used by legacy code and users of the unstable/alpha/legacy "encapsulated API".

  Access to these now less public types should not be required for users of the `@public` "declarative API" exposed in the `fluid-framework` package, but can still be accessed for those who need them under the `/legacy` import paths.
  The full list of such types is:
  - `SharedTree` as exported from `@fluidframwork/tree`: It is still exported as `@public` from `fluid-framework` as `SharedObjectKind`.
  - `ISharedObjectKind`: See new `SharedObjectKind` type for use in `@public` APIs.
    `ISharedObject`
  - `IChannel`
  - `IChannelAttributes`
  - `IChannelFactory`
  - `IExperimentalIncrementalSummaryContext`
  - `IGarbageCollectionData`
  - `ISummaryStats`
  - `ISummaryTreeWithStats`
  - `ITelemetryContext`
  - `IDeltaManagerErased`
  - `IFluidDataStoreRuntimeEvents`
  - `IFluidHandleContext`
  - `IProvideFluidHandleContext`

  Removed APIs:
  - `DataObjectClass`: Usages replaced with `SharedObjectKind`.
  - `LoadableObjectClass`: Replaced with `SharedObjectKind`.
  - `LoadableObjectClassRecord`: Replaced with `Record<string, SharedObjectKind>`.
  -

- Update to TypeScript 5.4 ([#21214](https://github.com/microsoft/FluidFramework/pull/21214)) [0e6256c722](https://github.com/microsoft/FluidFramework/commit/0e6256c722d8bf024f4325bf02547daeeb18bfa6)

  Update package implementations to use TypeScript 5.4.5.

- fluid-framework: Remove several types from `@public` scope ([#21142](https://github.com/microsoft/FluidFramework/pull/21142)) [983e9f09f7](https://github.com/microsoft/FluidFramework/commit/983e9f09f7b10fef9ffa1e9af86166f0ccda7e14)

  The following types have been moved from `@public` to `@alpha`:
  - `IFluidSerializer`
  - `ISharedObjectEvents`
  - `IChannelServices`
  - `IChannelStorageService`
  - `IDeltaConnection`
  - `IDeltaHandler`

  These should not be needed by users of the declarative API, which is what `@public` is targeting.

## 2.0.0-rc.4.0.0

### Minor Changes

- Deprecated members of IFluidHandle are split off into new IFluidHandleInternal interface [96872186d0](https://github.com/microsoft/FluidFramework/commit/96872186d0d0f245c1fece7d19b3743e501679b6)

  Split IFluidHandle into two interfaces, `IFluidHandle` and `IFluidHandleInternal`.
  Code depending on the previously deprecated members of IFluidHandle can access them by using `toFluidHandleInternal` from `@fluidframework/runtime-utils/legacy`.

  External implementation of the `IFluidHandle` interface are not supported: this change makes the typing better convey this using the `ErasedType` pattern.
  Any existing and previously working, and now broken, external implementations of `IFluidHandle` should still work at runtime, but will need some unsafe type casts to compile.
  Such handle implementation may break in the future and thus should be replaced with use of handles produced by the Fluid Framework client packages.

## 2.0.0-rc.3.0.0

### Major Changes

- Packages now use package.json "exports" and require modern module resolution [97d68aa06b](https://github.com/microsoft/FluidFramework/commit/97d68aa06bd5c022ecb026655814aea222a062ae)

  Fluid Framework packages have been updated to use the [package.json "exports"
  field](https://nodejs.org/docs/latest-v18.x/api/packages.html#exports) to define explicit entry points for both
  TypeScript types and implementation code.

  This means that using Fluid Framework packages require the following TypeScript settings in tsconfig.json:
  - `"moduleResolution": "Node16"` with `"module": "Node16"`
  - `"moduleResolution": "Bundler"` with `"module": "ESNext"`

  We recommend using Node16/Node16 unless absolutely necessary. That will produce transpiled JavaScript that is suitable
  for use with modern versions of Node.js _and_ Bundlers.
  [See the TypeScript documentation](https://www.typescriptlang.org/tsconfig#moduleResolution) for more information
  regarding the module and moduleResolution options.

  **Node10 moduleResolution is not supported; it does not support Fluid Framework's API structuring pattern that is used
  to distinguish stable APIs from those that are in development.**

### Minor Changes

- fluid-framework: Replace SharedObjectClass with new ISharedObjectKind type. [97d68aa06b](https://github.com/microsoft/FluidFramework/commit/97d68aa06bd5c022ecb026655814aea222a062ae)

  The static objects used as SharedObjectClass now explicitly implement the new ISharedObjectKind type.
  SharedObjectClass has been removed as ISharedObjectKind now fills that role.
  LoadableObjectCtor has been inlined as it only had one use: an external user of it can replace it with `(new (...args: any[]) => T)`.

## 2.0.0-rc.2.0.0

### Minor Changes

- fluid-framework: SharedObject classes are no longer exported as public ([#19717](https://github.com/microsoft/FluidFramework/issues/19717)) [ae1d0be26d](https://github.com/microsoft/FluidFramework/commits/ae1d0be26d61453cff316b3f622a9f3647149167)

  `SharedObject` and `SharedObjectCore` are intended for authoring DDSes, and thus are only intended for use within the Fluid Framework client packages.
  They is no longer publicly exported: any users should fine their own solution or be upstreamed.
  `SharedObject` and `SharedObjectCore` are available for now as `@alpha` to make this migration less disrupting for any existing users.

## 2.0.0-rc.1.0.0

### Minor Changes

- Updated server dependencies ([#19122](https://github.com/microsoft/FluidFramework/issues/19122)) [25366b4229](https://github.com/microsoft/FluidFramework/commits/25366b422918cb43685c5f328b50450749592902)

  The following Fluid server dependencies have been updated to the latest version, 3.0.0. [See the full changelog.](https://github.com/microsoft/FluidFramework/releases/tag/server_v3.0.0)
  - @fluidframework/gitresources
  - @fluidframework/server-kafka-orderer
  - @fluidframework/server-lambdas
  - @fluidframework/server-lambdas-driver
  - @fluidframework/server-local-server
  - @fluidframework/server-memory-orderer
  - @fluidframework/protocol-base
  - @fluidframework/server-routerlicious
  - @fluidframework/server-routerlicious-base
  - @fluidframework/server-services
  - @fluidframework/server-services-client
  - @fluidframework/server-services-core
  - @fluidframework/server-services-ordering-kafkanode
  - @fluidframework/server-services-ordering-rdkafka
  - @fluidframework/server-services-ordering-zookeeper
  - @fluidframework/server-services-shared
  - @fluidframework/server-services-telemetry
  - @fluidframework/server-services-utils
  - @fluidframework/server-test-utils
  - tinylicious

- Updated @fluidframework/protocol-definitions ([#19122](https://github.com/microsoft/FluidFramework/issues/19122)) [25366b4229](https://github.com/microsoft/FluidFramework/commits/25366b422918cb43685c5f328b50450749592902)

  The @fluidframework/protocol-definitions dependency has been upgraded to v3.1.0. [See the full
  changelog.](https://github.com/microsoft/FluidFramework/blob/main/common/lib/protocol-definitions/CHANGELOG.md#310)

- shared-object-base: SharedObject processGCDataCore now takes IFluidSerializer rather than SummarySerializer ([#18803](https://github.com/microsoft/FluidFramework/issues/18803)) [396b8e9738](https://github.com/microsoft/FluidFramework/commits/396b8e9738156ff88b62424a0076f09fb5028a32)

  This change should be a no-op for consumers, and `SummarySerializer` and `IFluidSerializer` expose the same consumer facing APIs. This change just makes our APIs more consistent by only using interfaces, rather than a mix of interfaces and concrete implementations.

## 2.0.0-internal.8.0.0

Dependency updates only.

## 2.0.0-internal.7.4.0

Dependency updates only.

## 2.0.0-internal.7.3.0

Dependency updates only.

## 2.0.0-internal.7.2.0

Dependency updates only.

## 2.0.0-internal.7.1.0

Dependency updates only.

## 2.0.0-internal.7.0.0

### Major Changes

- Dependencies on @fluidframework/protocol-definitions package updated to 3.0.0 [871b3493dd](https://github.com/microsoft/FluidFramework/commits/871b3493dd0d7ea3a89be64998ceb6cb9021a04e)

  This included the following changes from the protocol-definitions release:
  - Updating signal interfaces for some planned improvements. The intention is split the interface between signals
    submitted by clients to the server and the resulting signals sent from the server to clients.
    - A new optional type member is available on the ISignalMessage interface and a new ISentSignalMessage interface has
      been added, which will be the typing for signals sent from the client to the server. Both extend a new
      ISignalMessageBase interface that contains common members.
  - The @fluidframework/common-definitions package dependency has been updated to version 1.0.0.

- Server upgrade: dependencies on Fluid server packages updated to 2.0.1 [871b3493dd](https://github.com/microsoft/FluidFramework/commits/871b3493dd0d7ea3a89be64998ceb6cb9021a04e)

  Dependencies on the following Fluid server package have been updated to version 2.0.1:
  - @fluidframework/gitresources: 2.0.1
  - @fluidframework/server-kafka-orderer: 2.0.1
  - @fluidframework/server-lambdas: 2.0.1
  - @fluidframework/server-lambdas-driver: 2.0.1
  - @fluidframework/server-local-server: 2.0.1
  - @fluidframework/server-memory-orderer: 2.0.1
  - @fluidframework/protocol-base: 2.0.1
  - @fluidframework/server-routerlicious: 2.0.1
  - @fluidframework/server-routerlicious-base: 2.0.1
  - @fluidframework/server-services: 2.0.1
  - @fluidframework/server-services-client: 2.0.1
  - @fluidframework/server-services-core: 2.0.1
  - @fluidframework/server-services-ordering-kafkanode: 2.0.1
  - @fluidframework/server-services-ordering-rdkafka: 2.0.1
  - @fluidframework/server-services-ordering-zookeeper: 2.0.1
  - @fluidframework/server-services-shared: 2.0.1
  - @fluidframework/server-services-telemetry: 2.0.1
  - @fluidframework/server-services-utils: 2.0.1
  - @fluidframework/server-test-utils: 2.0.1
  - tinylicious: 2.0.1

- Minimum TypeScript version now 5.1.6 [871b3493dd](https://github.com/microsoft/FluidFramework/commits/871b3493dd0d7ea3a89be64998ceb6cb9021a04e)

  The minimum supported TypeScript version for Fluid 2.0 clients is now 5.1.6.

## 2.0.0-internal.6.4.0

### Minor Changes

- Some stack traces are improved ([#17380](https://github.com/microsoft/FluidFramework/issues/17380)) [34f2808ee9](https://github.com/microsoft/FluidFramework/commits/34f2808ee9764aef21b990f8b48860d9e3ce27a5)

  Some stack traces have been improved and might now include frames for async functions that weren't previously included.

## 2.0.0-internal.6.3.0

Dependency updates only.

## 2.0.0-internal.6.2.0

### Minor Changes

- Remove use of @fluidframework/common-definitions ([#16638](https://github.com/microsoft/FluidFramework/issues/16638)) [a8c81509c9](https://github.com/microsoft/FluidFramework/commits/a8c81509c9bf09cfb2092ebcf7265205f9eb6dbf)

  The **@fluidframework/common-definitions** package is being deprecated, so the following interfaces and types are now
  imported from the **@fluidframework/core-interfaces** package:
  - interface IDisposable
  - interface IErrorEvent
  - interface IErrorEvent
  - interface IEvent
  - interface IEventProvider
  - interface ILoggingError
  - interface ITaggedTelemetryPropertyType
  - interface ITelemetryBaseEvent
  - interface ITelemetryBaseLogger
  - interface ITelemetryErrorEvent
  - interface ITelemetryGenericEvent
  - interface ITelemetryLogger
  - interface ITelemetryPerformanceEvent
  - interface ITelemetryProperties
  - type ExtendEventProvider
  - type IEventThisPlaceHolder
  - type IEventTransformer
  - type ReplaceIEventThisPlaceHolder
  - type ReplaceIEventThisPlaceHolder
  - type TelemetryEventCategory
  - type TelemetryEventPropertyType

## 2.0.0-internal.6.1.0

Dependency updates only.

## 2.0.0-internal.6.0.0

### Major Changes

- Upgraded typescript transpilation target to ES2020 [8abce8cdb4](https://github.com/microsoft/FluidFramework/commits/8abce8cdb4e2832fb6405fb44e393bef03d5648a)

  Upgraded typescript transpilation target to ES2020. This is done in order to decrease the bundle sizes of Fluid Framework packages. This has provided size improvements across the board for ex. Loader, Driver, Runtime etc. Reduced bundle sizes helps to load lesser code in apps and hence also helps to improve the perf.If any app wants to target any older versions of browsers with which this target version is not compatible, then they can use packages like babel to transpile to a older target.

## 2.0.0-internal.5.4.0

Dependency updates only.

## 2.0.0-internal.5.3.0

Dependency updates only.

## 2.0.0-internal.5.2.0

Dependency updates only.

## 2.0.0-internal.5.1.0

Dependency updates only.

## 2.0.0-internal.5.0.0

Dependency updates only.

## 2.0.0-internal.4.4.0

Dependency updates only.

## 2.0.0-internal.4.1.0

Dependency updates only.