Studio Developer Manual / Version 2406.1

6. Structure of the Studio Client Workspace

The studio-client workspace is a pnpm workspace consisting of various packages. It has the following file structure:

File structure of the workspace

apps/studio-client/
  ├── apps/                 // app specific packages
  ├── global/               // global packages
  ├── node_modules/         // dependencies managed by the package
  │                            manager generated during installation
  ├── shared/               // packages shared between apps
  ├── tools/                // helper tools
  ├── check-pnpm.js         // script making sure pnpm is used
  ├── Dockerfile            // Build studio-client image
  ├── Dockerfile.tasks      // node version number for nvm
  ├── Dockerfile.tooling    // meta data about the workspace for the
  ├── entrypoint.sh         // entrypoint triggered while starting client
  ├── nginx.conf.template   // nginx configuration for studio-client
  │                            image
  ├── package.json          // meta data about the workspace for pnpm
  ├── pnpm-lock.yaml        // pnpm lock file to fixate versions
  ├── pnpm-workspace.yaml   // pnpm workspace configuration
  ├── README.adoc           // general information
  ├── .dockerignore         // files to ignore during docker build
  └── .gitignore            // files to ignore by Git

Note

Depending on the used IDE additional files or folders might be existing. The node_modules folder is created after running pnpm install for the first time.

The workspace structure follows a strict pattern regarding the location of packages and their responsibilities:

As the name implies, the shared folder contains libraries that are or can be shared across multiple other packages in the workspace. None of these packages should have a dependency to any package in the apps, global or tooling folders.
The first level of sub folders inside the shared folder declares if the package utilizes Ext JS (ext) or if all code contained inside the package is written in plain JavaScript (js). While plain JavaScript packages can be used like any other npm package the former require special treatment by the Jangaroo tooling and are most likely exclusive to being used inside applications built with Ext JS.
The apps folder contains apps or libraries shared among the apps. While they can have a dependency to packages in the shared folder, none of these packages should have a dependency to any package in the global or tooling folders.
Inside the apps folder, the first level of subfolders identifies the app that the corresponding package belongs to, for example, main or workflow.
The extension-config and extensions folders on the second level have special relevance for the extensions tool (see Section 4.1.5, “Project Extensions” in Blueprint Developer Manual ).
The global folder contains only the studio package which aggregates all available apps into a single bundle, which can be deployed on a web server. It may depend on every other package except packages in the tooling folder.
Packages inside the tooling folder are used to provide some helper tools when migrating from an older CoreMedia studio-client workspace. Their usage is usually explained in the corresponding release notes.
You should never depend on any package inside this folder after you have successfully migrated as they might change or be removed entirely in an AEP.

Note

There is no check inside the workspace that enforces that the patterns described above are actually applied CoreMedia. However, CoreMedia highly suggest to stick to this structure as CoreMedia might provide helper tools that will not adapt to any custom workspace layout and which you might not be able to use without manual adjustments otherwise.

File structure of a Jangaroo package

While every package needs at least a package.json file containing the meta data for pnpm, packages that represent a Jangaroo project usually have the following file structure:

some-package/
  ├── build/                // output folder for builds and tests
  ├── dist/                 // distribution folder for publishing
  │                            into the npm registry
  ├── node_modules/         // dependencies managed by the package
  │                            manager generated during installation
  ├── jest/                 // contains unit tests for jest
  ├── joounit/              // contains unit tests for joounit
  ├── sencha/               // additional files for sencha build
  ├── src/                  // the actual sources of the package
  ├── .eslintrc.js          // linter configuration
  ├── jangaroo.config.js    // jangaroo configuration
  └── package.json          // meta data about the package for pnpm

Not all folders exist for all packages in the workspace. The build and dist folders are only created after executing certain pnpm scripts.

The jest, joounit and src folders each contain a tsconfig.json file for TypeScript which is generated after building the package for the first time. Part of this configuration will mirror your (transitive) dependencies and will be modified if there were are changes in the dependency tree. CoreMedia recommends to check in these files to have code completion immediately after checking out a branch without having to build everything first.

Note

Currently it is not possible to add custom configuration to the tsconfig.json file.

Search Results

Table Of Contents

Filter

Studio Developer Manual / Version 2406.1

6. Structure of the Studio Client Workspace

File structure of the workspace

File structure of a Jangaroo package

Search Results