{"version":"2.1.246","anchor":"plugin-javascript-modules-stay-off-and-the-flag-reader-is-of","canonical_anchor":"plugin-javascript-modules-stay-off-and-the-flag-reader-is-of","heading":"Plugin JavaScript modules stay off, and the flag reader is off even for them","tier":"soon","area":"Plugins","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246\/e\/plugin-javascript-modules-stay-off-and-the-flag-reader-is-of","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246","markdown":"### Plugin JavaScript modules stay off, and the flag reader is off even for them\n\nPlugin JavaScript modules can read flags, abort turns and detect the app, but they do not load at all.\n\n**What**\n\nThe plugin host API gains three verbs: one reporting whether the caller is the desktop app or a terminal, one aborting a turn, and one reading a feature flag as `$.flag.value(name, fallback)`. All of this sits behind `tengu_plugin_hooks_modules`, whose in-source default is false, so plugin JS modules do not load at all without a server value and the loader logs that it skipped them and names the flag. The flag reader is doubly off: it refuses unless an internal-build check passes, and that check is a constant false here.\n\n**Details**\n\n- With the flag reader refusing, the `flag` object is filtered out of the method table advertised to plugins.\n- The plugin-types prompt and doc injection now opens on the same rollout flag instead of its previous condition.\n\n**Evidence**\n\n`reads a feature flag, which this build has no table of`\n\n- Area: Plugins\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}