Open kaeedo opened 1 year ago
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
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!
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
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
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
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: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:
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 optionThanks a bunch