dev-only folder, mostly ignored during build

Describe the problem

I wish SvelteKit can better help me organize code that are not for production, ie testing, debugging, other auxiliary or metaprogramming needs.

Currently if (dev) { } is often needed to write code just for the dev environment. This colocation of production and non-production code is more susceptible to clutter and boilerplate.

Separating such code into its own folder can allow more granular version control and likely leads to better code/file structures and more efficient builds.

Describe the proposed solution

The proposal is in addition to the dev from $app/environment, specify a $lib/dev folder that is designated for non-production code. It should behave like rest of $lib but build largely ignores these files.

For example

<DevComponent>
  <Content/>
</DevComponent>
<AfterThought/>

is built as if we wrote

<Content/>
<AfterThought/>

Here are the details. I do not know anything about the inner workings to know if they are feasible or even beneficial.

1. $lib/dev js and svelte.js files are skipped from build.
2. For $lib/dev svelte files:
   a. upon build, its children or default slot is merged with that of the parent component or page or layout, meaning children of <DevComponent> are added to children of the parent.
   b. upon build, any parameters passed to the children via {@render children(param)} are omitted. children can always be defined to have a default values for params. This avoids having to analyze param and see if it requires retaining additional code. Support for parameters can always be added later.
   c. slot fallback is removed, ie what happens if the component never existed
   d. upon build, everything else is removed / not rendered, including contexts, stores, scripts, tags, svelte blocks, components, css, and other snippets or slots.
   e. allow children or default slot only at the top level, including no wrapper <div>. Give console warning if violated. This ensures that css tree is not disturbed between dev and production, and minimizes non-static analysis steps.
3. All exports from $lib/dev are typed to be optional (ie Type | undefined), so anyone using these files are aware of the fact that they may be unavailable. Importing to another $lib/dev file can type narrow to simply Type, as they will be both available or both unavailable.
4. When a non-$lib/dev file imports from a $lib/dev file, remove/tree-shake such imports at build time.
5. Allow dev folder location to be changed in configs.

Alternatives considered

Heavily augment svelte-inspector to somehow run a debug script, with this being the component. It has the down side of not persisting the debug script and possibly involves a lot of copy pasting. In contrast, the proposal is more versatile.

One of my current use cases is detecting if component is in a {#if} block, but only in dev server. I assume anything other than wrapper components (such as one defined in $lib/dev) will involve major compiler updates.

Importance

nice to have

Additional Information

No response

No files, tests, or entry points are named. Start by locating SvelteKit's build and compiler handling for $lib and $app/environment, then assess the requested $lib/dev behavior against the listed build, rendering, typing, tree-shaking, and configuration requirements. Done means determining whether the proposal is feasible and implementing or documenting the complete behavior.