You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Here are the details. I do not know anything about the inner workings to know if they are feasible or even beneficial.
$lib/dev js and svelte.js files are skipped from build.
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.
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.
When a non-$lib/dev file imports from a $lib/dev file, remove/tree-shake such imports at build time.
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
The text was updated successfully, but these errors were encountered:
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 thedev
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
is built as if we wrote
Here are the details. I do not know anything about the inner workings to know if they are feasible or even beneficial.
$lib/dev
js and svelte.js files are skipped from build.$lib/dev
svelte files:a. upon build, its
children
or default slot is merged with that of the parent component or page or layout, meaningchildren
of<DevComponent>
are added tochildren
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.$lib/dev
are typed to be optional (ieType | 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 simplyType
, as they will be both available or both unavailable.$lib/dev
file imports from a$lib/dev
file, remove/tree-shake such imports at build time.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
The text was updated successfully, but these errors were encountered: