{"version":"2.1.248","anchor":"module-initialisation-moved-from-first-use-to-startup","canonical_anchor":"module-initialisation-moved-from-first-use-to-startup","heading":"Module initialisation moved from first use to startup","tier":"notice","area":"Bundling","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/module-initialisation-moved-from-first-use-to-startup","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Module initialisation moved from first use to startup\n\nNearly all modules now load their code at startup instead of on first use, shifting timing.\n\n**What**\n\nAlmost every internal module used to have its top-level code wrapped in a deferred initialiser that ran the first time something imported it. Those wrappers drop from 5815 to 105 in this build, and the bodies are now plain top-level code. Work that used to happen on first call now happens during process load.\n\n**Details**\n\n- Affects constant tables, regexes, embedded asset reads, schema definitions and lazily built singletons.\n- Many diff hunks that look like \"a function became a constant\" are just an empty placeholder stub being replaced by the real value.\n\n**Evidence**\n\n`var It = [\"managedSourcesBehavior\", \"wslInheritsWindowsSettings\"];`\n\n- Area: Bundling\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}