No longer possible to enable debug mode on a per-plugin basis?

Developers: Plugin & API
1

Hi, I’m the author of the hot-reload plugin that is used by many Obsidian plugin devs. Unfortunately, since the addition of app.debugMode(), it’s no longer possible to enable sourcemap handling during a plugin reload, because Obsidian has switched from checking the “debug-mode” localstorage at load time, to checking a vault-specific “DebugMode” at application start. (Meaning it ignores any intermediate changes even to the new localstorage variable.)

Would it be possible to at least check the new localstorage variable at plugin load time, and/or make app.debugMode() not reload the entire app? Or is there something that has changed with the sourcemap stripping behavior that means it really isn’t possible to turn it on or off without reloading the entire Obsidian app? Thanks.

2

I raised a very similar problem once they trimmed this support

There is a workaround that works without setting app.debugMode(), though.

If you add at the end of main.js

(newline)/* nosourcemap */(end of file)

then, the sourcemaps won’t be trimmed, even if debug mode is not enabled

I even made an esbuild plugin that adds this magic string on npm run dev

Maybe you can consider adding this magic string within your Hot Reload plugin. I can send a corresponding PR, if you are interested.

3

Yes, I’d planned to use that workaround as a fallback, at least in ophidian/build’s esbuild config. But the only way hot-reload can do it would be to patch the vault adapter read() function during hot reload to add the string automatically. (Making hot-reload write to the plugin files themselves is not an option as that would break my ability to test a plugin in multiple Obsidian versions simultaneously using Sandboxie.)

I’m just not keen on patching the vault adapter if I can possibly avoid it.

1 Like
4

Can you elaborate what’s the problem if you edit main.js and add the magic line? How exactly will it break your testing?

5

I use Sandboxie to have more than one Obsidian version installed, and it has a copy-on-write filesystem. This works fine as long as I only modify the plugin on my actual (non-virtual, non-sandboxed) filesystem, because all sandboxes see the updates. However, if any of the sandboxes writes to the file, then the file now belongs to the sandbox and it won’t see any updates from the main filesystem from then on, until I wipe the sandbox and re-created. So having hot-reload write to the file would break my workflow, unless it was a setting I turned off in the sandboxed version somehow. (Which would be a pain to track.)

So for my uses, it makes more sense to temporarily patch the vault.adapter.read() method to add the extra string, rather than rewriting the file on disk. (And my prototype of that seems to work.)

A bigger problem, though, seems to be that my sourcemaps are always… off? Or nearly always. As in, they don’t always quite match up with the source, often being several lines off. I’ve started just saying the heck with it and turning off the sourcemaps anyway because it’s easier to debug correct JS than incorrectly-aligned TypeScript.

1 Like
6

I had the issue with source maps being a few lines off and it was because of my hand-written esbuild plugins where I did some replacements in the compiled code.
Once I ensured I always replace in the way, I don’t modify amount on the lines, my source maps became valid again