Suggestions for enhancements to the plugin template

[stroiman]

I think that the template could use a few improvements;

The suggestions suggested here are all something that I have WIP in a plugin I'm working on. The UI work is in a very early stage, and so maybe the solutions will change. At any rate my WIP is in this branch: https://github.com/stroiman/obsidian-frontmatter-smith/tree/config-ui

All of these are changes that I intend to include in my own fork of the template. So far the fork was focused on adding support for TDD; adding mocha, as well as tsx (typescript execute) to support using ESM in watch mode.

My previous plugins didn't have any significant UI complexity, but my current WIP requires more complexity; which exposed some problems that need to be solved in order to achieve an efficient development workflow.

The issues, and my solutions to the problems are describe below.

Question is; are these things you agree with could make their way into the plugin template?

If that is the case, I'd be glad to engage in a discussion about what form, and to which extend that should be included, and make a PR - separating my personal preferences from what we can agree on as a common ground.

CSS name conflict handling

It appears that plugin CSS style sheets are loaded into global scope. This can easily lead to naming conflicts where two plugin uses the same css class names; and therefore affect the layout of each other. Experienced we developers are aware of this; but many plugin developers have little web development experience.

CSS modules could be a solution to that, and I've set that up in my own project to use css modules in such a way that class names are automatically prefixed with the plugin id (read from manifest.json so you don't need to update esbuild configuration).

If this was included as part of the template, and encouraged as a recommended strategy; the problem of class name conflicts should be solved.

My project has a bit of complication because esbuild generates a main.css - but obsidian requires it to be called styles.css, so now the css build output is registered as a new entry point, generating two css files instead of one.

If Obsidian could recognise "main.css" as an alternative to "styles.css", that would make the build process simpler (But that's a feature request for Obsidian itself; not the plugin template)

Using vite and a browser for fast visual feedback for UI code

A very important aspect of development efficiency is the feedback cycle. And having to reload the plugin Obsidian (even though that can be automated) to see the effects is less than ideal. In my case; the UI complexity is in the configuration of the plugin; which requires me to open the settings.

Being able to see the effect of my changes without leaving the editor is crucial for me working effectively with code.

For that purpose, I have setup vite to act as a dev server; allowing me to work on UI code and immediately see the visual effects of any changes; Any change to either a .js or .css file will immediately be reflected in the browser.

I was able to do that because the UI code is written in such a way that it is decoupled from the plugin API; it only depends on my internal model.

This required me to duplicate the CSS module configuration. Vite is build on top of esbuild - so perhaps it's possible to have some shared configuration; or possibly use vite to build, instead of esbuild.

This right now also include Obsidian's own stylesheet (which I think is what is in "app.css"?), to make CSS variables, and native styling available in the dev server.

TDD support

This becomes a little more opinionated; as different developers prefer different tools.

But to me, TDD is a very important for efficiency, as it's not about tests; but about fast feedback just for small pieces of code (my previous plugin actually worked the first time I actually loaded it in Obsidian)

That is why I have setup mocha; as it provides the fastest feedback cycle of all the tools I've so far tested. Jest; which has gained a lot of popularity is actually slow compared to mocha.

So far, I have only written tests for the logical parts; as I am just getting started on UI work. But I will probably also write tests for UI behaviour; in which case I need to add '@testing-library/dom' as well as a javascript DOM implementation like jsdom or happy-dom.