CoreMedia Content Cloud v11 Upgrade Guide / Version 2110
Table Of ContentsAfter merging your converted custom Blueprint workspace with CoreMedia v11 as described in Merge with v11.2110.1 Workspace is finished successfully, there are some mandatory and some optional steps to take as follows.
Before you start, make sure your Studio Client workspace root is the current directory:
$ cd apps/studio-client
Update Core Dependency Versions
Even after merging with a v11 Blueprint workspace, dependencies of your custom packages (former custom Maven modules) still reference the 2107 CoreMedia core npm artifacts (for example
2107.6.0-4.1.15) in theirpackage.json. Such dependencies must be updated to the corresponding v11 artifacts, which is easily achieved using the new pnpm tooling:$ pnpm -r update "@coremedia/studio-client.*@2110.1.0"
Build the Workspace
Continue by building the Studio Client pnpm workspace:
$ pnpm install $ pnpm -r run build
You may encounter further errors resulting from incompatibilities between your customizations and v11 (breaking) changes or as a result of type errors caused by your changes in existing Blueprint packages. See other sections of this Upgrade Guide, release notes for component "Studio Client" and 4 for guidance on how to fix such errors.
Start Studio Client from Custom v11 Workspace
Now that the v11-upgraded workspace has been built, again try to start Studio. You now of course need a running v11 system, either started locally or somewhere in your CI. Use the same command as above to start Studio Client:
$ pnpm -r run start --filter ./apps/main/app -- --proxyTargetUri=https://studio.acme.com/
and open
http://localhost:3000in the browser. Your customized v11 Studio should load.Although TypeScript can find more errors at build-time, many of these are still ignored (see Fixing TypeScript Type Errors), and of course, some bugs only occur at run-time. Thus, you may encounter JavaScript errors in the browser, resulting from incompatibilities between your customizations and v11 (breaking) changes. Try to narrow down which component is causing the error by analyzing error stack traces, debugging and adding console output. Again, consult all sections of this Upgrade Guide as well as all relevant release notes to resolve these issues. Contact CoreMedia support to help you with intractable errors.
The converter cannot always generate "green" TypeScript code from ActionScript code, for several reasons:
TypeScript supports much more precise types through generics, overloading, function signatures etc. Using a more precise type may identify existing type errors or implicit assertions that lead to type errors.
TypeScript's DOM API, using these features, provides stronger typing, reporting type errors that went unnoticed using jangaroo-browser's ActionScript DOM API.
Like for ActionScript, CoreMedia generated a TypeScript API from the official Sencha Ext JS documentation. Since the Ext JS ActionScript API is named "Ext AS", the new API is consequently called "Ext TS". Again, errors may surface because TypeScript can express (JavaScript) types more precisely. For example if a parameter is documented be a
stringor anumber, the only possible ActionScript type is "any" (*), while TypeScript allows to describe this usingstring | number. Such differences between Ext AS and Ext TS may lead to type errors in your code. Also, there may still be bugs and inconsistencies in the new Ext TS API. Please report such issues to CoreMedia support if you think you encountered one.While in ActionScript, an Ext JS Config object type was inaccurately represented by the class itself, the two are now clearly separated. The converter cannot always determine whether the ActionScript type 'Foo' is supposed to refer to the class 'Foo' or its Config type. In ambiguous cases, the type remains the class type, causing type errors if actually the Config type was meant.
It is not mandatory to fix all type errors to upgrade your Studio Client customizations to v11, but it is highly recommended for mid- to long-term maintenance of your code. Each npm package contains a file
jangaroo.config.js, which again contains a settingignoreTypeErrors. This setting is true after initial conversion, so that you can build and run Studio in spite of type errors. However, if your customizations in an existing Blueprint npm package, which in v11 does not setignoreTypeErrors, cause type errors, you must either re-introduce the property or fix these type errors.When fixing type errors, start from a "bottom" package in the workspace dependency hierarchy, i.e. a package with no dependencies to other packages in your local npm workspace. Build, fix type errors, until no more remain, then set
ignoreTypeErrorsto false (or remove the entry altogether) in the correspondingjangaroo.config.jsto save this state. Continue working up your way in the dependency hierarchy, until eventually, the whole Studio Client workspace builds without type errors.Before starting to fix type errors, you should make yourself familiar with the new TypeScript syntax and specific utilities CoreMedia offers to integrate with Ext JS. Section 7.3, “Changes Between ActionScript and TypeScript for Developers” contains a comprehensive description of how Studio ActionScript, MXML and properties files are (automatically) converted to TypeScript. This should help you as an experienced Studio Client developer to transfer your knowledge to the new syntax.
