preference for alternatives over cdk.json

[0xdabbad00]

The strategy I've been using has been to use a yaml file for my config values, as yaml allows comments and thus is a more human friendly format. I also like having a separate config file, especially for projects I plan to open-source, because it allows for the configuration settings to be separate from the rest of the code for the project, so you won't have conflicts in git pulls or other updates. I don't know if this goes against the expectations of the CDK project, but seems to work better for my use cases.

[kevinslin]

yeah, when possible, I prefer YAML because of comments and increased flexibility.
and +1 on keeping config separate in open source projects.
how do you import the YAML into the context?

[0xdabbad00]

I've only just started using this idea for a CDK project. For another project I have, I include a .example version of the file that the person needs to copy to a file named without that extension. Then the version of the file without the extension is .gitignore'd and the person is responsible for backing up that file somehow on their own. This isn't ideal, as it's very likely that no one backs up a copy of that file, but I haven't found a better strategy.

Example:
https://github.com/duo-labs/cloudmapper/tree/master/config

[kevinslin]

wonder if it makes sense to use something like jsonnet. you get the best of all worlds since it is meant to serialize to json and has lots of high level features like comments, loops and imports (it's basically a programming language that happens to output json). if you wanted to version control config separately, you could keep the specific local config in a different folder and version control just that config.

// cdk.jsonnet
local ctx = import 'cdk.local.libsonnet';
{
  dev: {
    // root domain for web portal
    domain: ctx['dev']['domain'],
   ...
  },
  prod: {
  ...
  }
}

that being said, this should only be an issue for public projects. for org projects, there should be a standard config in prod at least. dev config might differ but that could be fixed either via something like jsonnet or getting those values from the shell env

[fshields]

I think your desire for a separate context file has been realized. In the latest CDK release it seems that a cdk.context.json file (at the same path level as your cdk.json file) will allow you to store your environmentals in a way that you can choose to eliminate from a code commit.

Unfortunately, I have been struggling to find good documentation on this.

[fshields]

Well, I actually did find some more info on cdk.context.json in this reported issue.

Evidently, "cdk.json is for humans to manage and cdk.context.json is for the CLI to manage. Both should be checked-in to ensure reproducbility of your synthesis."

[asterikx]

Is there a reason to use JSON/YAML over TypeScript (or any other programming language) for configuration? What's wrong about a config.ts exporting a config object? Then you could benefit from type-checking, refactoring etc.

[kevinslin]

mainly so that it is readable for multiple systems/languages. if you don't have the need for that, expressing your config as a native object has lots of benefits

…

On Tue, Apr 14, 2020 at 9:16 AM Erik Müller ***@***.***> wrote: Is there a reason to use JSON/YAML over TypeScript (or any other programming language) for configuration? What's wrong about a config.ts exporting a config object? Then you could benefit from type-checking, refactoring etc. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADD52PECPXX2JAH7LXK3H3RMSD7RANCNFSM4IKPC5UA> .