Plugins System

[AngelMunoz]

This is very very early days, but one common issue I see around other similar tools that aren't node based is the need for plugins to transform and modify files when they get loaded by the server either for dev or whatever

I have three ideas regarding on how to read plugins from users,

• load an assembly with functions and execute them
• Load an F# script with the F# compiler services and execute a particular set of defined functions
• Load javascript files using - https://github.com/sebastienros/jint

For the Plugin API I'm still undecided but I'd very likely check what others are doing

[AngelMunoz]

web/dev-server has a really good explanation on how they are doing the plugin stuff
https://modern-web.dev/docs/dev-server/writing-plugins/overview/

In regards of the F# scripts (which I think those would be far easier to handle and extensible for people there's previous work like that on migrondi

[AngelMunoz]

Ideally... we would load the session and scripts once since it seems quite expensive to be running that each time there's a request

For that approach to work I think there would need to be a separate package so users could do something like

#r "nuget: Perla.Plugins"

open Perla.Plugins

// do the plugin work
[ { new IServe with 
       override _.Serve(context: IContext): Task<IResourceResolution> = (* ... Do the plugin work ....*) } 
  {  new ITransform with 
       override _.Transform(file: IFileData): Task<IFileData> = (* ... Do the plugin work ....*) }
]

I'm using the I prefix just to note that these are interfaces that we should be able to consume from the server in a particular middleware to consume these plugins/hooks

[nojaf]

It would be nice if we could indeed hook up an fsx script to transform files.
Would all plugins need to run in the same interactive session?

I'm thinking of transforming sass to CSS.
I have an F# script that does but I need to run it outside of Perla right now.
Not the end of the world or anything but would be nice if I could hook something up.

[AngelMunoz]

I have a small PoC about that in this experimental sample https://github.com/AngelMunoz/Perla/tree/experiments-types/src/experiments/Calcetate

feel free to check it out and actually let me know if the Plugin.fsx is something that you would like to use to author plugins

I still need to work out a lifecycle and likely rewrite the whole middleware pipeline to move current transforms and compilation phases to plugins, but it is more-less in line with what I have in mind

[AngelMunoz]

The current problem I have with a plugin system right now is that we have a disconnection between dev time (the dev server) and build time (a single esbuild run with the --bundle flag) that pretty much locks us to whatever esbuild is doing at the moment and thus making things like import { Component } from "./Component.vue" nearly to impossible at build time, while we can change that to import { Component } from "./Component.js" that means that at some point we had to parse the typescript/javascript/else-script files and switch the extensions in the imports, in runtime that's far simpler because we can fall back to the http request file's path and switch .vue for .js

What I'm currently thinking here is to have the following stages for build time that could also work for dev time

• At server/build start map out the file system (https://github.com/xoofx/zio looks like a great tool to have this)
• build a supported extensions list from the currently registered plugins (like js, css, html, vue, scss)
• Transpile files via plugin
  • Pre-compile all files in the file system's registered paths (we would need to change how we treat mounted-directories)
    • For build time it would be just single file pass and output to the file system as is
    • For dev time it would be reading the existing compiled file from the file system in case it already exists and returning the output or compile new changes and return the new output
• For Build time at this point every file has been compiled in the file system and now should have valid imports with valid extensions
  • Example: File.vue -> File.js

    <template><h1>Hey there!</h1></template>
    <script>
    import Component from './Component.vue'
    import Component2 from './Component2.vue'
    </script>

    import Component from './Component.js'
    import Component2 from './Component2.js'
    ...

  We can now just run esbuild --bundle on the final build to ensure all gets minified and bundled as esbuild usually does

Notes

I think it is better that users always, always use the File.js and File.css extension, even if the file system has a File.svelte file this can help us at the end to just run esbuild normally we can still make sure to check all of the file system and compile the files with help of the supported extensions list

I will start trying to make a build time PoC of the above with sass files (because that's the plugin I have in mind right now) and then proceed to other kind of files if needed (like xml-json or similar)