Incremental adoption

Because of the way DMNO is designed you can adopt it incrementally, both in terms of the services you use it with and the features you use within those services.

A few different options

There are a few different ways you can adopt DMNO incrementally:

Service by service:

• You can start by adding DMNO to a single service, and then gradually add it to more services as needed. If you’re in a monorepo, it’s best to start with some root config and then incrementally add a service at a time.

Feature by feature:

• Mark items as required and sensitive
• Add descriptions to items to automatically attach documentation
• Add specific types to each of the config items
• Then add custom validation rules, coercion, and custom types
• Set values from the schema itself (e.g., functions, switching based on environment)
• Add plugins to fetch the config values from a secure source

In your code:

• We will support your existing methods of using env vars (e.g., process.env in Node.js, import.meta.env in Vite, etc) while you migrate to DMNO, by reinjecting your resolved config items as strings. You won’t get type completion, full IntelliSense, and you won’t get an error if you try to access a variable that doesn’t exist, unfortunately.
• Once you’ve added DMNO to your project, you can start using the DMNO_CONFIG/DMNO_PUBLIC_CONFIG object in your code to access your config items. This will give you full type completion and IntelliSense, and actionable error messages if you try to access a variable that doesn’t exist or fails validation.
• You can use dmno run to run your services with DMNO, and use dmno dev while you’re actively working on your schema and your apps/services will autorefresh when you make changes to your schema.

Caution

When using process.env you will always get back a string, even if the value is a number or boolean. This can lead to bugs that are hard to track down.