Generate all files in ./.xp-codegen directory

2.0.0 release

1. Changes to output directory

It isn't considered best practice to generate files into the ./src directory, so all files will be generated into the ./.xp-codegen directory instead.

The directory structure inside ./.xp-codegen is the same as inside the ./src/main/resouces directory, so we can do a trick in tsconfig.json where we set two rootDirs, and "overlays" ./.xp-codegen over ./src/main/resouces.

Do the following change to you tsconfig.json:

{
  "compilerOptions": {
    "target": "es5",
    "strict": true,
    "sourceMap": true,
    "allowJs": true,
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "strictNullChecks": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "types": ["node", "enonic-types"],
+   "rootDirs": [
+     "./src/main/resources",
+     "./.xp-codegen"
+   ],
  },
  "include": [
+   "./.xp-codegen/**/*",
    "./src/main/resources/**/*"
  ],
  "exclude": ["./build/*"]
}

You will still need to change all the interface imports in your application (sorry about that), but the new syntax is much nicer if you ask me.

// The old way to import
-import type { Article } from "../../content-types/article/article";
-import type { Employee } from "../../content-types/employee/employee";

// The new way to import
+import type { Article, Employee } from "../../content-types";

// Or you can access globally defined type like this:
+type Article = XP.ContentTypes["com.mysite.app:article"];

The globally declared XP.ContentTypes interface will allow us to do some really cool stuff in enonic-types, since can have the association between the name of the content type, and the structure of the data.

2. Remove other Gradle tasks then generateTypeScript

The other Gradle tasks were either little used, or useless, so all other tasks then generateTypeScript has been removed.

generateTypeScript will now generate .d.ts files (not .ts files). A benefit with this is that .d.ts files doesn't emit any JavaScript when running Webpack.

3. Changes to part configs

Part configs has also gotten new paths to be imported from, and can now be found in index.d.ts in the same directory.

Lets say we have a part parts/article-view/article-view.ts.

-import type { ArticleViewConfig } from "./article-view-config.ts";
+import type { ArticleView } from ".";

4. Arrays in interfaces

We have changed the interfaces used for Arrays from Array<T> to Array<T> | T. This is to reflect the structure XP actually returns, and force the developer to use forceArray().

Note
If XP only have one entry in the array, it will return that value instead of an Array with one value.

5. __typename for interfaces

Example:

// WARNING: This file was automatically generated by "no.item.xp.codegen". You may lose your changes if you edit it.
export interface Article {
  /**
   * Preface
   */
  preface: string;

  /**
   * Body
   */
  body: string;
+
+ /**
+  * GraphQL name. Also used for separating unions in TypeScript
+  */
+ __typename?: "no_mysite_app_Article_Data";
}

This attribute is never set in TypeScript-land, only in GraphQL-land. But it exists in the interface to allow us to split discrete unions cleanly. We can now have tools that looks up the type name based on the shape of the data.

6. Generated XData interface

A new global declaration can be found under ./site/x-data/index.d.ts, and can be accessed globally by XP.XData. This will have the structure of the x-data fields specified in the application.

If you have 3rd party x-data that is being used, you can also declare those as globals, and the interfaces will be merged.

---

Enjoy the new release everybody! And sorry about changing all the import paths! 😬