In the 2207 Blueprint workspace, certain TypeScript source patterns have been simplified. The changes described below can be applied automatically by a tool CoreMedia provides. To do so, make sure your CoreMedia Blueprint workspace is in a clean VCS state. Then start by enabling all extensions:

cd workspace-configuration/extensions
mvn extensions:list -DextensionsFile=extensions.txt
mvn extensions:sync "-Denable=*"

Now invoke the new source code update tool:

cd ../..
cd apps/studio-client
pnpm install
pnpm dlx @coremedia/studio-client.tools.update-ts-source-code@~1.0.0

Restore the state of any previously disabled extensions:

cd ../..
cd workspace-configuration/extensions
mvn extensions:sync -DextensionsFile=extensions.txt
rm extensions.txt

Add and commit all resulting changes with an appropriate commit message. Now, the number of possible conflicts in Studio Client TypeScript code when merging with CoreMedia Blueprint AEP 2207 is reduced drastically.

The following sections describe the improved TypeScript syntax that the tool applies and that should be used when you write Studio TypeScript code from now on.

New class static block syntax

Since version 4.7, TypeScript fully supports ECMAScript class static blocks, so the workaround syntax using a private static field with an "immediately evaluated function" (IEF) can now be simplified.

Before:

class Foo {
  static #static = (() => {
    console.log("Foo is being initialized!");
  })();
}

After:

class Foo {
  static {
    console.log("Foo is being initialized!");
  }
}

Simplify this access before super() call

In Ext JS, it is often required to use this in the constructor before calling super(). According to ECMAScript and thus TypeScript class semantics, this is not allowed and results in an error. To still be able to use TypeScript classes for Ext JS development, we found a workaround described in the following. Assume there is a class Bar with a constructor that takes a string and a boolean, an Ext JS subclass could look like so:

class Foo extends Bar {
  #field: string;
  constructor(a: string) {
    super(...(() => {
      /* all code accessing 'this' before 'super()': */
      this.#field = a;
      // super args must be returned and spread ('...'):
      return [a + "!", this.#compute()];
    )());
    /* code after super call: */
    console.log(this.#field);
  }
  #compute(): boolean { ... }
}

The pattern is slightly simpler when there is just one super call parameter, but is still hardly comprehensible and cumbersome to write.

The new workaround that reads and writes simpler is to define an alias for this and use @ts-expect-error to ignore the resulting error exactly in that line. The new syntax for the code above looks like so:

class Foo extends Bar {
  #field: string;
  constructor(a: string) {
    // @ts-expect-error Ext JS semantics
    const this$ = this;
    // same code as inside the IEF with every 'this' is replaced by 'this$':
    this$.#field = a;
    // normal super call:
    super(a + "!", this$.#compute());
    /* code after super call: */
    console.log(this.#field);
  }
  #compute(): boolean { ... }
}

(CMS-21747)