Initial feedback on plugin authoring

[kaeedo]

Hi, I'm the guy that pinged you over on mastodon :)

First, some unrelated feedback on perla:

After running dotnet perla new MyProject it gives a selection of templates: Awesome!
Then it shows hints about quick access commands:

Perla: This template has quick access commands:
Perla: perla new -t solid
Perla: Next time you can run perla new -id perla.templates.solid.js

Also cool,

Finally it says successful. I think it would be nice if it could also show a hint about how to start the newly created template. Something like:

Perla: To see your new website, run perla serve and open your browser

or similar.

---

Now for the plugin feedback. I understand everything is still very early in development, and you've been spending your time on more important things. That being said, from the initial look at the markdown plugin it seems that the primary purpose of perla plugins is to allow loading file types not natively supported by esbuild. Is this a correct assumption, or were you also envisioning other plugins that transform/extract data from existing files as they travel through the pipeline? Or is this better suited for esbuild plugins (which would require node again -.- )

Context: I want to write a plugin to allow usage of TailwindCSS via their standalone executable. This would require looking at existing files, and then creating a new/replace an existing css file in the output.

As far as the debugging experience goes, maybe I haven't poked around enough with it, but it would be nice to have access to the perla context of "input" directory and "output" directory, and being able to access the vfs to see what files exist there.

Lastly, add some kind of hint that perla-esbuild-plugin is a required plugin when setting the plugins array option

Thanks a bunch

[AngelMunoz]

Hey there! thanks for trying it out I truly appreciate it! It always helps to figure out rough edges that I often overlook!

Finally it says successful. I think it would be nice if it could also show a hint about how to start the newly created template.

Oh indeed this is good suggestion, I'll open a ticket for that

---

It seems that the primary purpose of perla plugins is to allow loading file types not natively supported by esbuild. Is this a correct assumption

The primary purpose is to allow files that aren't allowed in a browser e.g. anything that is not HTML/CSS/JS while esbuild helps a lot in some areas, sadly it can't cover everything and there might be future alternatives to esbuild (bun.sh) so that's why I made it a plugin

Were you also envisioning other plugins that transform/extract data from existing files as they travel through the pipeline?

In this case I want the plugins to form some sort of a pipeline, the file gets read when perla starts, perla goes through each plugin and if the plugin supports that file it gets processed if the resulting file can be processed by other plugins after in the pipeline go through it again until we're done.

Here's a rough diagram that kind of explains it

Right now we process each file in isolation, so as long as you can compile/transpile/transform a single file with the plugin then you can technically do a transformation pipeline like

• .custom-dsl -> .md -> .html

In this case you had a custom dsl compiler in your company/job/life that can produce markdown, you can leverage then the markdown plugin afterwards to produce HTML

This means

1. Plugins run each file in isolation (the most limiting aspect of this system)
2. Plugins have an execution order
3. Plugins can be "chained" to produce multiple kinds of results

Or is this better suited for esbuild plugins (which would require node again -.- )

I want to avoid node as a dependency as much as possible (and dotnet for that matter as well) so we can't go that way, maybe when bun.sh is out we can figure out something there as it is an all-in-one solution and replacement for node which may help us in the future

Context: I want to write a plugin to allow usage of TailwindCSS via their standalone executable. This would require looking at existing files, and then creating a new/replace an existing css file in the output.

I'm not fully aware of how tailwind css works (specially around classes in html files and css files) but after a quick glance to that link, I think this is very much possible! you can pass your css files through it and get css back!

As far as the debugging experience goes, maybe I haven't poked around enough with it, but it would be nice to have access to the perla context of "input" directory and "output" directory, and being able to access the vfs to see what files exist there.

I'm still thinking how to approach this situation, as I said above every file runs in isolation so it doesn't make much sense right now to show you what is the contents of the vfs, there are some things that we may be able to tweak around the vfs in the future so I'm keen to listen to feedback here as well

Lastly, add some kind of hint that perla-esbuild-plugin is a required plugin when setting the plugins array option

The perla schema should warn you about that if I remember correctly... but I'll make sure to add a warning in the console there as well!

[kaeedo]

Thanks for the detailed response, especially that flowchart! The way that TailwindCSS works is by scanning all your markup files (html/jsx/tsx/whatever you define in tailwind.config.js) and extracting any matching css class names (such as bg-red-500 or mx-4). It then overwrites the input.css with a list of compiled classes (such as .mx-4 { margin-right: 1rem; margin-left: 1rem)

So looking at the flowchart, the best time to run this plugin would be after all the individual transforms are complete and before copying into the VFS. That way, the development files could remain untouched as they are with e.g. ViteJS, but the served file includes the generated CSS classes

[AngelMunoz]

If that's the case... I think you may not even need a perla plugin, in this case a project would be structured like this:

styles
  input.css // the input file for tailwind
src
  styles.css // output file for tailwind
  App.fsproj 
  App.fs
  ...
index.html
perla.json
tailwind.config.js // include F#/js/ts/jsx/tsx files in config

module App

open Fable.Core

JsInterop.importSideEffects "./styles.css"

// ... the rest of the app

running both side by side

• tailwindcss -i ./styles/input.css -o ./src/styles.css --watch
• perla serve

Perla should be able to pick up any changes made to the src/styles.css file and reflect them

I have yet to test this but I think this is a viable option.

This might hint to a different mechanism to allow Perla to run external tools controlled by the user, this feels like a plugin but it is not in the same category of the ones I had in mind when writing the plugin API for perla

[kaeedo]

running both side by side

 tailwindcss -i ./styles/input.css -o ./src/styles.css --watch
 perla serve

Perla should be able to pick up any changes made to the src/styles.css file and reflect them

Can confirm this works. This is good enough for my use case for now. Thanks.

This might hint to a different mechanism to allow Perla to run external tools controlled by the user,

Just as an idea, you could do it similar to how fable has the --run command which runs another command after fable is through with the compilation