You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
default.ts contains a complete 'development' configuration, and is included in VCS.
production.ts contains a partial configuration of overwrites that are applied conditional on the NODE_ENV environment variable, and is included in VCS.
local.ts contains a partial configuration of overwrites that are always applied, but is not included in VCS.
The config library will deep-merge the structures exported from these files in a consistent, predictable order.
In practise, this is good for various reasons ...
default.ts acts as living documentation for the overwrite keys I can choose to add to local.ts, production.ts.
I don't have to repeat myself or remember to copy things from default.ts to production.ts when I make changes.
I can specify machine-specific configuration in local.ts without affecting collaborators.
I can store sensitive credentials in local.ts without exposing them via my VCS.
Notably, though, for this pattern to work, I sometimes need to use null or undefined values in production.ts in order to 'unset' values defined by default.ts.
So when I came to trying to implement this pattern for a Python project using .toml files in place of .ts, I was fairly dismayed when I found out I can't have null values in .toml files!
Motivating use-case 2
Say I have an 'optional' value which I load from a .toml file.
foo = "bar"# foo can be omittedbaz = "qux"
As long as the defined value for foo is not null-ish, it is obvious to any contributor to my project simply by looking in the config file that they can amend the value of foo to have some effect on the project's behaviour.
But if the defined value for foois null-ish, I can either
Comment out the line
Omit foo from the config file
Both of these make it considerably less obvious to an arbitrary individual that foo is something they can amend the value of.
Other remarks
null and undefined are simply 'sentinel' values roughly meaning 'the absence of a value'.
If we want to get really silly, we could say TOML already supports null-ish values ...
foo -> null because its value is exactly the chosen sentinel value baz -> "qux" because its value is not the chosen sentinel value
fin.
since null-ish values are clearly 100% supported already (/s), what difference does adding a null keyword make? it would save people the effort of running openssl or duplicating all the keys in their files :0)
I want to be arguing over null/nil/none/undefined, not about whether TOML needs null!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Motivating use-case 1
I come from the JavaScript ecosystem where we have a package called config.
I really like the pattern it implements. I end up setting up my projects like this:
Now,
default.ts
contains a complete 'development' configuration, and is included in VCS.production.ts
contains a partial configuration of overwrites that are applied conditional on theNODE_ENV
environment variable, and is included in VCS.local.ts
contains a partial configuration of overwrites that are always applied, but is not included in VCS.config
library will deep-merge the structures exported from these files in a consistent, predictable order.In practise, this is good for various reasons ...
default.ts
acts as living documentation for the overwrite keys I can choose to add tolocal.ts
,production.ts
.default.ts
toproduction.ts
when I make changes.local.ts
without affecting collaborators.local.ts
without exposing them via my VCS.Notably, though, for this pattern to work, I sometimes need to use
null
orundefined
values inproduction.ts
in order to 'unset' values defined bydefault.ts
.So when I came to trying to implement this pattern for a Python project using
.toml
files in place of.ts
, I was fairly dismayed when I found out I can't havenull
values in.toml
files!Motivating use-case 2
Say I have an 'optional' value which I load from a
.toml
file.As long as the defined value for
foo
is not null-ish, it is obvious to any contributor to my project simply by looking in the config file that they can amend the value offoo
to have some effect on the project's behaviour.But if the defined value for
foo
is null-ish, I can eitherfoo
from the config fileBoth of these make it considerably less obvious to an arbitrary individual that
foo
is something they can amend the value of.Other remarks
null
andundefined
are simply 'sentinel' values roughly meaning 'the absence of a value'.If we want to get really silly, we could say TOML already supports
null
-ish values ...Strategy 1: 'flags'
foo
->null
becausefoo_is_null
baz
->"qux"
becausenot baz_is_null
Strategy 2: bring your own sentinel value
select an arbitrary value that is unlikely to ever show up in common use ...
and use it to represent
null
valuesfoo
->null
because its value is exactly the chosen sentinel valuebaz
->"qux"
because its value is not the chosen sentinel valuefin.
since
null
-ish values are clearly 100% supported already (/s), what difference does adding anull
keyword make? it would save people the effort of runningopenssl
or duplicating all the keys in their files :0)I want to be arguing over
null
/nil
/none
/undefined
, not about whether TOML needsnull
!Beta Was this translation helpful? Give feedback.
All reactions