uuid: - value: 8be3d8d9-4e73-49db-93a6-83349ac1af05 langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:18+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: 'Feature flags should be short-lived' created: - value: '2024-03-11T00:00:00+00:00' changed: - value: '2025-05-11T09:00:18+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2024/03/11/feature-flags-should-be-short-lived langcode: en body: - value: |
Today, I posted a tweet with a screenshot of some code.
When previously working on the Versa CLI tool, I had a TODO comment saying "What if there are multiple languages?".
Versa is a tool for standardising commands between different languages and frameworks, but some projects, like my personal website, use multiple languages.
The website is powered by Sculpin, a static site generator written in PHP (so there is a composer.json file) and node to compile the front-end assets (so there is also a package.json file).
Depending on the language, commands like versa install
will need to execute a different command - e.g., composer installor
npm install` (or an equivalent node package manager).
I added PHP support first, so if a composer.json file is found, the PHP command is run as the default.
What I thought was for projects with multiple languages, to prompt the user to select the language when running the command if no explicit language is set.
This led me to do a spike of using Symfony Console's choice
method to see what that would look like so I could add a screenshot to the GitHub issue.
Once I'd finished with the spike, rather than deleting the code, I wrapped it in an if (false)
condition so it wouldn't be executed, but I could still re-enable it in the future.
The screenshot in the tweet showed this, along with the text "Minimum viable feature flag."
This is only supposed to be there for a short time until I revisit the code and implement the feature I was spiking on.
If it would be a long time before I looked at it again, I'd take a different approach.
One of the main rules of using feature flags is that they should be short-lived.
It's less than ideal to read through a codebase and see it scattered with feature flags that are no longer needed and were used to release a feature several months ago, but the flag hasn't been removed.
A feature flag is a temporary solution for separating the deployment of code from the release of a change.
Once it's been released, the flag should be removed.
format: full_html processed: |Today, I posted a tweet with a screenshot of some code.
When previously working on the Versa CLI tool, I had a TODO comment saying "What if there are multiple languages?".
Versa is a tool for standardising commands between different languages and frameworks, but some projects, like my personal website, use multiple languages.
The website is powered by Sculpin, a static site generator written in PHP (so there is a composer.json file) and node to compile the front-end assets (so there is also a package.json file).
Depending on the language, commands like versa install
will need to execute a different command - e.g., composer installor
npm install` (or an equivalent node package manager).
I added PHP support first, so if a composer.json file is found, the PHP command is run as the default.
What I thought was for projects with multiple languages, to prompt the user to select the language when running the command if no explicit language is set.
This led me to do a spike of using Symfony Console's choice
method to see what that would look like so I could add a screenshot to the GitHub issue.
Once I'd finished with the spike, rather than deleting the code, I wrapped it in an if (false)
condition so it wouldn't be executed, but I could still re-enable it in the future.
The screenshot in the tweet showed this, along with the text "Minimum viable feature flag."
This is only supposed to be there for a short time until I revisit the code and implement the feature I was spiking on.
If it would be a long time before I looked at it again, I'd take a different approach.
One of the main rules of using feature flags is that they should be short-lived.
It's less than ideal to read through a codebase and see it scattered with feature flags that are no longer needed and were used to release a feature several months ago, but the flag hasn't been removed.
A feature flag is a temporary solution for separating the deployment of code from the release of a change.
Once it's been released, the flag should be removed.
summary: null field_daily_email_cta: { }