cloudflare: broken setting value types

[risen228]

Expected Behavior

The value property in ZoneSetting from @cdktf/provider-cloudflare should accept string values like 'on', 'off', 'full', etc., as these are valid values for many Cloudflare zone settings. The TypeScript type definitions should correctly reflect the actual data types Cloudflare API accepts for settings.

Actual Behavior

The current type definition for the value property in ZoneSetting only accepts objects, not primitive values like strings. This forces developers to use type assertions (as any) to bypass TypeScript errors when setting common string values, as shown in this example:

new zoneSetting.ZoneSetting(this, 'example', {
  zoneId: zoneId,
  settingId: 'always_use_https',
  value: 'on' as any,
})

Without the as any assertion, TypeScript generates an error indicating that a string value cannot be assigned to the value property, even though 'on' is a perfectly valid setting value for the always_use_https setting in Cloudflare's API. For such settings, any object values causing the errors like that:

Error: failed to make http request

with cloudflare_zone_setting.example

PATCH
"https://api.cloudflare.com/client/v4/zones/<redacted>/settings/always_use_https":
400 Bad Request {"success":false,"errors":[{"code":1007,"message":"Invalid
value for zone setting always_use_https"}],"messages":[],"result":null}

Steps to Reproduce

1. Install the @cdktf/provider-cloudflare package in a TypeScript project
2. Import the zoneSetting module
3. Try to create a new ZoneSetting instance with a string value for common Cloudflare settings:

   new zoneSetting.ZoneSetting(this, 'cluster_setting_always_use_https', {
     zoneId: clusterZone.zoneId,
     settingId: 'always_use_https',
     value: 'on' as any, // Type assertion needed to avoid errors
   })

4. Observe the TypeScript error indicating that a string cannot be assigned to the value property
5. Note that using value: 'on' as any works as a workaround but is not an ideal solution as it bypasses type checking

The issue affects multiple Cloudflare settings including but not limited to:

• always_use_https (accepts 'on' / 'off')
• automatic_https_rewrites (accepts 'on' / 'off')
• ssl (accepts 'off' / 'flexible' / 'full' / 'strict')
• security_level (accepts 'off' / 'essentially_off' / 'low' / 'medium' / 'high' / 'under_attack')

This type definition issue requires unnecessary type assertions throughout the codebase and reduces the DX and benefits of TypeScript's static type checking.

Versions

cdktf debug
language: typescript
cdktf-cli: 0.20.11
node: v20.18.1
cdktf: 0.20.11
constructs: 10.4.2
jsii: null
terraform: 1.10.3
arch: arm64
os: darwin 24.3.0
providers
@cdktf/provider-cloudflare (PREBUILT)
terraform provider version: 5.1.0
prebuilt provider version: 12.1.0
cdktf version: ^0.20.0

Providers

@cdktf/provider-cloudflare (PREBUILT)
terraform provider version: 5.1.0
prebuilt provider version: 12.1.0
cdktf version: ^0.20.0

Gist

No response

Possible Solutions

Modify the ZoneSetting type to accept either string values or objects for the value property using a union type:

value: string | object | boolean | number

Workarounds

Continue using type assertions with as any as in the example:

new zoneSetting.ZoneSetting(this, 'cluster_setting_always_use_https', {
   zoneId: clusterZone.zoneId,
   settingId: 'always_use_https',
   value: 'on' as any,
 })

Or create wrapper class / function:

class TypedZoneSetting extends zoneSetting.ZoneSetting {
  constructor(
    scope: Construct,
    id: string,
    config: Omit<zoneSetting.ZoneSettingConfig, 'value'> & {
      value: object | string
    },
  ) {
    super(scope, id, { ...config, value: config.value as object })
  }
}

Anything Else?

No response

References

May be related:

• cloudflare provider: 12.0.0 is horribly broken #3822

Help Wanted

• I'm interested in contributing a fix myself

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment