Inline options should take priority over environment options

[Rich-Harris]

Describe the problem

At present, environment options take priority over inline options:

https://github.com/sveltejs/vite-plugin-svelte/blob/bd915c1317127a716a22cdd8c44d66d766e0f513/packages/vite-plugin-svelte-inspector/src/index.js#L57-L66

This feels wrong — if I need to e.g. disable the inspector on a specific project for a while, I should be able to do so without editing my ~/.[ba|z]shrc or prefixing my pnpm dev command with a string that I will have to figure out without the benefit of typechecking.

Describe the proposed solution

if (environmentOptions === true) {
- inspectorOptions = defaultInspectorOptions;
+ inspectorOptions = {
+   ...defaultInspectorOptions,
+   ...configFileOptions,
+   ...options
+ };
} else {
  inspectorOptions = {
    ...defaultInspectorOptions,
+   ...environmentOptions,
    ...configFileOptions,
+   ...options
-   ...options,
-   ...(environmentOptions || {})
  };
}

(Side-note — pretty sure the || {} is superfluous — obj = { ...undefined } is fine.)

Alternatives considered

none

Importance

would make my life easier

[Rich-Harris]

Actually, better still:

-if (environmentOptions === true) {
-  inspectorOptions = defaultInspectorOptions;
-} else {
-  inspectorOptions = {
-    ...defaultInspectorOptions,
-    ...configFileOptions,
-    ...options,
-    ...(environmentOptions || {})
-  };
-}
+inspectorOptions = {
+  ...defaultInspectorOptions,
+  ...(environmentOptions === true ? { enabled: true } : environmentOptions),
+  ...configFileOptions,
+  ...options
+};

[dominikg]

I'm on the fence about this. If file options take precedence, then users can no longer override them via env, which makes env less useful. Esp if someone checked in a keyCombo, i want to be able to change that. Or if someone set it to enabled: false but i still want to use it...

SVELTE_INSPECTOR_OPTIONS=false pnpm dev even feels like less effort than temporary editing a file, could make a shell alias for it if its too much to type. If you prefer editing a file, that projects .env could work too, which has the advantage that its less likely to be in gits focus so no accidental add+commit.

[dominikg]

thought about some open tickets in this repo today and this one is still strange. you can easily override even a default env (if you set one, opting in to a globally enabled inspector) with an inline env var as shown in my previous comment. a possible slight inconvenince of a user with a non-default env is less of my concern than taking away other users ability to override options set in a file that do not align with their personal dx.