@fluidframework/container-loader 2.0.0-internal.6.3.2 → 2.0.0-internal.6.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fluidframework/container-loader",
-  "version": "2.0.0-internal.6.3.2",
+  "version": "2.0.0-internal.6.4.0",
   "description": "Fluid container loader",
   "homepage": "https://fluidframework.com",
   "repository": {
@@ -35,16 +35,16 @@
     "temp-directory": "nyc/.nyc_output"
   },
   "dependencies": {
-    "@fluid-internal/client-utils": ">=2.0.0-internal.6.3.2 <2.0.0-internal.6.4.0",
-    "@fluidframework/container-definitions": ">=2.0.0-internal.6.3.2 <2.0.0-internal.6.4.0",
-    "@fluidframework/container-utils": ">=2.0.0-internal.6.3.2 <2.0.0-internal.6.4.0",
-    "@fluidframework/core-interfaces": ">=2.0.0-internal.6.3.2 <2.0.0-internal.6.4.0",
-    "@fluidframework/core-utils": ">=2.0.0-internal.6.3.2 <2.0.0-internal.6.4.0",
-    "@fluidframework/driver-definitions": ">=2.0.0-internal.6.3.2 <2.0.0-internal.6.4.0",
-    "@fluidframework/driver-utils": ">=2.0.0-internal.6.3.2 <2.0.0-internal.6.4.0",
+    "@fluid-internal/client-utils": ">=2.0.0-internal.6.4.0 <2.0.0-internal.6.5.0",
+    "@fluidframework/container-definitions": ">=2.0.0-internal.6.4.0 <2.0.0-internal.6.5.0",
+    "@fluidframework/container-utils": ">=2.0.0-internal.6.4.0 <2.0.0-internal.6.5.0",
+    "@fluidframework/core-interfaces": ">=2.0.0-internal.6.4.0 <2.0.0-internal.6.5.0",
+    "@fluidframework/core-utils": ">=2.0.0-internal.6.4.0 <2.0.0-internal.6.5.0",
+    "@fluidframework/driver-definitions": ">=2.0.0-internal.6.4.0 <2.0.0-internal.6.5.0",
+    "@fluidframework/driver-utils": ">=2.0.0-internal.6.4.0 <2.0.0-internal.6.5.0",
     "@fluidframework/protocol-base": "^1.0.1",
     "@fluidframework/protocol-definitions": "^1.1.0",
-    "@fluidframework/telemetry-utils": ">=2.0.0-internal.6.3.2 <2.0.0-internal.6.4.0",
+    "@fluidframework/telemetry-utils": ">=2.0.0-internal.6.4.0 <2.0.0-internal.6.5.0",
     "debug": "^4.1.1",
     "double-ended-queue": "^2.1.0-0",
     "events": "^3.1.0",
@@ -53,13 +53,13 @@
     "uuid": "^9.0.0"
   },
   "devDependencies": {
-    "@fluid-internal/test-loader-utils": ">=2.0.0-internal.6.3.2 <2.0.0-internal.6.4.0",
+    "@fluid-internal/test-loader-utils": ">=2.0.0-internal.6.4.0 <2.0.0-internal.6.5.0",
     "@fluid-tools/build-cli": "^0.22.0",
     "@fluidframework/build-common": "^2.0.0",
     "@fluidframework/build-tools": "^0.22.0",
-    "@fluidframework/container-loader-previous": "npm:@fluidframework/container-loader@2.0.0-internal.6.3.1",
+    "@fluidframework/container-loader-previous": "npm:@fluidframework/container-loader@2.0.0-internal.6.3.0",
     "@fluidframework/eslint-config-fluid": "^2.1.0",
-    "@fluidframework/mocha-test-setup": ">=2.0.0-internal.6.3.2 <2.0.0-internal.6.4.0",
+    "@fluidframework/mocha-test-setup": ">=2.0.0-internal.6.4.0 <2.0.0-internal.6.5.0",
     "@microsoft/api-extractor": "^7.34.4",
     "@types/double-ended-queue": "^2.1.0",
     "@types/events": "^3.0.0",

package/src/connectionManager.ts

@@ -432,21 +432,7 @@ export class ConnectionManager implements IConnectionManager {
 	}
 
 	/**
-	 * Sends signal to runtime (and data stores) to be read-only.
-	 * Hosts may have read only views, indicating to data stores that no edits are allowed.
-	 * This is independent from this._readonlyPermissions (permissions) and this.connectionMode
-	 * (server can return "write" mode even when asked for "read")
-	 * Leveraging same "readonly" event as runtime & data stores should behave the same in such case
-	 * as in read-only permissions.
-	 * But this.active can be used by some DDSes to figure out if ops can be sent
-	 * (for example, read-only view still participates in code proposals / upgrades decisions)
-	 *
-	 * Forcing Readonly does not prevent DDS from generating ops. It is up to user code to honour
-	 * the readonly flag. If ops are generated, they will accumulate locally and not be sent. If
-	 * there are pending in the outbound queue, it will stop sending until force readonly is
-	 * cleared.
-	 *
-	 * @param readonly - set or clear force readonly.
+	 * {@inheritDoc Container.forceReadonly}
 	 */
 	public forceReadonly(readonly: boolean) {
 		if (readonly !== this._forceReadonly) {

package/src/container.ts

@@ -619,7 +619,21 @@ export class Container
 	}
 
 	/**
-	 * Tracks host requiring read-only mode.
+	 * Sends signal to runtime (and data stores) to be read-only.
+	 * Hosts may have read only views, indicating to data stores that no edits are allowed.
+	 * This is independent from this._readonlyPermissions (permissions) and this.connectionMode
+	 * (server can return "write" mode even when asked for "read")
+	 * Leveraging same "readonly" event as runtime & data stores should behave the same in such case
+	 * as in read-only permissions.
+	 * But this.active can be used by some DDSes to figure out if ops can be sent
+	 * (for example, read-only view still participates in code proposals / upgrades decisions)
+	 *
+	 * Forcing Readonly does not prevent DDS from generating ops. It is up to user code to honour
+	 * the readonly flag. If ops are generated, they will accumulate locally and not be sent. If
+	 * there are pending in the outbound queue, it will stop sending until force readonly is
+	 * cleared.
+	 *
+	 * @param readonly - set or clear force readonly.
 	 */
 	public forceReadonly(readonly: boolean) {
 		this._deltaManager.connectionManager.forceReadonly(readonly);

package/src/debugLogger.ts

@@ -108,6 +108,7 @@ export class DebugLogger implements ITelemetryBaseLogger {
 		}
 
 		// Print multi-line.
+		// eslint-disable-next-line @typescript-eslint/no-base-to-string
 		logger(`${name} ${payload} ${tick} ${stack}`);
 	}
 }

package/src/deltaManager.ts

@@ -368,7 +368,7 @@ export class DeltaManager<TConnectionManager extends IConnectionManager>
 		assert(this.connectionManager.connected, 0x238 /* "called only in connected state" */);
 
 		const pendingSorted = this.pending.sort((a, b) => a.sequenceNumber - b.sequenceNumber);
-		this.logger.sendErrorEvent({
+		this.logger.sendTelemetryEvent({
 			...event,
 			// This directly tells us if fetching ops is in flight, and thus likely the reason of
 			// stalled op processing

package/src/loader.ts

@@ -151,7 +151,7 @@ export interface ICodeDetailsLoader extends Partial<IProvideFluidCodeDetailsComp
 	 * Load the code module (package) that is capable to interact with the document.
 	 *
 	 * @param source - Code proposal that articulates the current schema the document is written in.
-	 * @returns - Code module entry point along with the code details associated with it.
+	 * @returns Code module entry point along with the code details associated with it.
 	 */
 	load(source: IFluidCodeDetails): Promise<IFluidModuleWithDetails>;
 }

package/src/packageVersion.ts

@@ -6,4 +6,4 @@
  */
 
 export const pkgName = "@fluidframework/container-loader";
-export const pkgVersion = "2.0.0-internal.6.3.2";
+export const pkgVersion = "2.0.0-internal.6.4.0";