Read AEM runmodes from Sightly

logic.js

var SlingSettingsService = Packages.org.apache.sling.settings.SlingSettingsService;
 
use(function () {
    // Get runmodes and transform them into an object that is easier to read for Sightly
    var runmodesObj = {};
    var runmodesSet = sling.getService(SlingSettingsService).getRunModes();
    var iterator = runmodesSet.iterator();
    
    while (iterator.hasNext()) {
        runmodesObj[iterator.next()] = true;
    }
    
    return {
        runmodes: runmodesObj
    }
});

template.html

<div data-sly-use.logic="logic.js">
    <p>Current runmodes: ${logic.runmodes}</p>
    <p data-sly-test="${logic.runmodes.samplecontent}">samplecontent runmode</p>
</div>

Custom run-modes -can- change after install, but not some of the baked in AEM run-modes: author/publish/crx2/crx3tar/etc

But as you precisely mentioned, it is very common to append custom runmodes to specify a logical instance e.g. publish,dev vs publish,prod1 etc then target sling:OsgiConfig nodes for OSGi service configurations as part of a build artifact. After one upacks the jar, they can easily adds custom run modes to their start shell/batch script, the custom run-modes and confirm these felix (/system/console/status-slingsettings)

@gabrielwalt If code should not act on the run mode, what's your suggestion for handling a scenario where different code is needed between a stage and prod environment? Adding an OSGi config just to distinguish the two and then using that in Sightly seems a bit overkill.