Using a TypeScript config file with CloudCannon

Community Support
1

Hi all :waving_hand:

I’m trying to use the TypeScript-based configuration file for CloudCannon as described here:
https://cloudcannon.com/documentation/developer-reference/typescript/

What I’ve done

  1. Installed the types:

    npm install --save-dev @cloudcannon/configuration-types

  2. Created a cloudcannon.config.ts file in the root of the project.

  3. Added a minimal config:

    import type { Configuration } from "@cloudcannon/configuration-types";

const config: Configuration = {
  collections_config: {
    media_types: {
      path: "src/content/media-types",
    },
  },
};

export default config;

  4. Pushed to the synced Git repository.

  5. CloudCannon triggered a rebuild as expected, with no visible errors.

What I expected

I expected the CloudCannon dashboard to show a “Media Types” collection for this site.

What I’m seeing

No “Media Types” collection appears in the dashboard. It looks like the config isn’t being picked up.

Questions

  1. Is there anything else required to make a TypeScript-based config active?
  2. Are there logs available that show how CloudCannon loads/parses the config (e.g. silent errors)?
  3. The TypeScript config file isn’t listed on this page:
    https://cloudcannon.com/documentation/developer-reference/configuration-file/
    Is it fully supported in production?
  4. Can npm packages be used inside a TypeScript-based config file?
    Being able to share configuration across multiple sites via versioned npm packages would be very helpful for our workflow.

Thanks in advance for any pointers!

1 Like
2

:wave: Hey Simon, while we do have TypeScript types for our configuration format, we do not currently support TypeScript files as configuration files.

:white_check_mark: The valid formats are YAML (cloudcannon.config.yml and cloudcannon.config.yaml) and JSON (cloudcannon.config.json). We parse this file in the browser (not during the build) to create your configuration, including your unsaved changes.

:pencil: We’ll make it clearer on that documentation page that TypeScript configuration files are not currently supported.

Note: some non-unified configuration (legacy) sites may still be using an older version of our configuration that does support a TypeScript file at build time.

3

Hi Ross,

Thanks for the clarification — that makes sense, especially the note about parsing happening in the browser rather than at build time. That explains why the TypeScript file wasn’t being picked up.

I have two follow-up questions:

  1. Are there any plans to support TypeScript-based configuration files (or at least some kind of npm-based extensibility) in the future?
    Being able to share configuration across multiple sites via versioned npm packages would be extremely helpful for our workflow.

  2. Does the configuration file strictly need to live inside the Git repository, or could it potentially be loaded from the built site itself?
    I’m wondering whether generating a JSON config during the build (e.g. compiling from TypeScript + npm dependencies) and exposing it as a route alongside the site would be a viable approach. That would give us the benefits of TypeScript and shared packages, while still producing a JSON file in the end.

Appreciate the insight — and thanks again for the quick response!

4

No worries, I can see how that would have been misleading.

  1. We don’t have anything specifically in the roadmap for TypeScript configuration files, but agree they would be useful.

  2. For now, yes the file should be inside the Git repository. There is technically a way to generate configuration for CloudCannon to use from the last successful build, which is what non-Unified Configuration sites mentioned previously use (and Bookshop). This does use the legacy format though, and we’d like to properly update this before documenting it as a recommend approach.

Using the output from the last successful build is something we have been moving away from recently. However there are still quite a few uses cases for doing so that we do want to support (e.g. generating configuration, pulling select data from an API).

5

Thanks for the clarification and the extra context.

Good to know generated configuration use cases are still something you’re looking to support. We’ll stick with a repo-based config for now and look forward to any updates around build-time generated configs.