jdpnielsen / uda-to-typescript Goto Github PK

License: MIT License

Shell 0.07% TypeScript 99.93%

uda-to-typescript's Introduction

uda-to-typescript

Command-line tool to convert Umbraco UDA files to Typescript types.

Install

npm install @jdpnielsen/uda-to-typescript

Quick Start

Usage: uda-to-typescript [options]

CLI to convert Umbraco UDA files to typescript definitions

Options:
  -V, --version          output the version number
  -c, --config <string>  Path for config file. Example: --config ./udaconvert.config.ts
  -i, --input <string>   Glob pattern to match. Example: --input ./files/*.uda
  -o, --output <string>  Where to write output file. Example: --output ./file.ts
  -d, --debug            enables verbose logging (default: false)
  -h, --help             display help for command

Examples:

  $ uda-to-typescript --version
  1.0.0

Without config

  $ uda-to-typescript --input ../your-umbraco-project/src/UmbracoProject/umbraco/Deploy/Revision/*.uda --output ./umbraco-sdk/types.ts

With config

 $ uda-to-typescript
 # or
 $ uda-to-typescript --config ./udaconvert.config.ts

Note: uda-to-typescript uses cosmic-config to locate config files.

File udaconvert.config.ts

import { defineConfig } from '@jdpnielsen/uda-to-typescript';

export default defineConfig({
  input: './petstore.yaml',
  output: './src/petstore.ts',
});

Provide custom datatypes

import { factory } from 'typescript';
import { defineConfig, dataTypes, HandlerConfig } from '@jdpnielsen/uda-to-typescript';

export default defineConfig({
	input: '../umbraco-boilerplate/src/UmbracoProject/umbraco/Deploy/Revision/*.uda',
	output: './src/umbraco/output.ts',
	dataTypes: {
		...dataTypes, // Provide default types
		'Custom.StatementEditor': {
			editorAlias: 'Custom.StatementEditor',
			/**
			 * Used to create any shared setup for the propertyEditor
			 */
			init: () => {
				return 'export type Statement = "key" | "val";';
			},
			/**
			 * Used to generate any dataType specifc types
			 * @example ```ts
			 * type MetatitleTextboxType = {
			 * 	statement: Statement;
			 * 	prop: string;
			 * };
			 * ```
			 */
			build: (dataType) => {
				return `type ${pascalCase(dataType.Name)}Type = {
					statement: Statement;
					prop: ${dataType.DatabaseType === 1 ? 'string' : 'unknown'};
				}`;
			},
			/**
			 * Used to generate any usage specific type/reference
			 * @example ```ts
			 * export type Metadata = BaseDocumentType<'metadata', {
			 * 	meta_title?: MetatitleTextboxType;
			 * }>;
			 * ```
			 */
			reference: (dataType) => `${pascalCase(dataType.Name)}Type`,
		},
	},
});

uda-to-typescript's People

Contributors

Watchers

uda-to-typescript's Issues

Image media type does not match Content API output

Image media type is missing focalPoint. Image media type is missing 'baked in' crops & does not receive property editor specific crops.

Support UmbracoForms.FormPicker property editor

FormPicker editor config should support expand parameter, which gets the json form definition embedded.

Add "take" query param to buildQueryParams function

The automated release is failing 🚨

🚨 The automated release from the `main` branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Media data type properties does retain information about field being non-required

Improve block type definition accuracy

Current Behavior

The current typedefinition for BaseBlock types are given as so:

export interface BaseDocumentType<
	Alias extends string = string,
	Properties extends ObjectType = ObjectType,
	Cultures extends { [culture: string]: ContentRoute } = EmptyObjectType,
> {
	id: string;
	name: string;
	createDate: string;
	updateDate: string;
	route: ContentRoute;
	contentType: Alias;
	cultures: Cultures;
	properties: Properties;
}

export interface BaseBlockType<Content extends BaseDocumentType = BaseDocumentType, Setting extends BaseDocumentType | null = BaseDocumentType | null> {
	content: Content;
	settings: Setting;
}

But the api outputs the following format:

{
  "name": "500",
  "createDate": "2022-11-07T23:07:42.38",
  "updateDate": "2022-11-07T23:07:52.283",
  "route": {
    "path": "/500",
    "startItem": {
      "id": "99a5b68d-095e-4cf0-9d00-9ad8aacee8f2",
      "path": "forside"
    }
  },
  "id": "1ecbcb74-9492-4755-bdc8-429be0695226",
  "contentType": "contentPage",
  "properties": {
    "meta_title": null,
    "meta_description": null,
    "meta_image": null,
    "umbracoUrlName": null,
    "blocks": {
      "items": [
        {
          "content": {
            "id": "8a7abd1d-08d1-4e86-8843-2d556fdb7acb",
            "contentType": "richtextBlock",
            "properties": {
              "content": {
                "markup": "<p>Internal server error</p>"
              }
            }
          },
          "settings": null
        }
      ]
    },
    "hero": null
  },
  "cultures": {}
}

The block interface is limited to id, contentType & properties fields.

Possible solution

We could introduce a BaseBlockComponent type definition:

export interface BaseBlockComponent<
	Alias extends string = string,
	Properties extends ObjectType = ObjectType,
> {
	id: string;
	contentType: Alias;
	properties: Properties;
}

export interface BaseBlockType<Content extends BaseBlockComponent = BaseBlockComponent, Setting extends BaseBlockComponent | null = BaseBlockComponent | null> {
	content: Content;
	settings: Setting;
}

Export Document expansion utilities

This would be helpful for actually consuming types together with the fetcher functions.