VNext

[AngelMunoz]

I've been doing a lot of refactoring in this branch in preparation to add the newer and most complex features to perla.

Please don't take anything in this branch as final until I actually say "this is how it's going to be" or something similar.

I mean it is very likely that I won't discard this branch given how much I have invested in it at this point.

Main things to look out in this PR for the moment (I will try to update as soon as I keep going forward)

• Goodbye Perla.Lib
  Perla Lib was a bad intent from my side to eventually expose each part of perla as a library that could be used by third parties, it turns out my code is a mess and won't work

• Hello Perla.Logger

  This is a very simple logger to standardize how perla does it's logging, perhaps in the future someone may want to improve it and switch the underlaying mechanism from printf to an actuall logger

• Hello Perla.PackageManager

  This is one of the most exciting bits for me, if you want to start playing with importmaps with your own server applications this library is for you, this will allow you to create importmaps that you will be able to write to your server-side templates and take advantace of client side npm-like dependency management without node!

• Hello Perla.Plugins

  This is the guilty piece that is driving everything, here I will add common code that will be used for Perla plugins, the API is not finalized but you can already see what I have in mind if you take a look at the project, it is very likely that I will also include the gist dependency manager for F# interactive I recently wrote so one can distribute plugins via gists rather than figuring out another distribution mechanism like the templating engine I wrote initially

• Hello Flan

  Flan is an interesting choice rather than writing it in F#/C# I chose Visual basic to write this piece it still be a CLI tool that will be dedicated to handle importmaps with the Perla.PacakgeManager this will be intended to be used individually and to also not depend on having .NET installed (a standalone cli tool) just like Perla binaries

Missing stuff

• dev, prod and testing dependencies

  The new Perla.PacakgeManager allows us to handle JS dependencies better, meaning that if we wanted we could handle dependencies for each environment although the API may be a little bit wonky due to differences between the JSPM Generator Api and the Skypack CDN/API it can be possible to support eventually

• Mounted Directories Virtual File System

  This is other of the driving motivations to add the zio library, it should greatly simplify mounting directories and working with what essentially be available for the dev/build server

• Test runner compatible with Web Test Runner

  Once the virtual file system support is there it will be easier to mount and run JS client side tests in perla which is a must to have for some users

There may be more things to track but for the moment these are basically the goals in mind for this PR hopefully I can get this done soon enough people can start testing around

[nojaf]

Hey there @AngelMunoz, very cool to see this progress on plugins!

Throwing out a shower thought here: have you considered using FSharp.Adaptive instead of Observables? The work Jimmy has been doing in FSAutocomplete is pretty impressive.

[AngelMunoz]

have you considered using FSharp.Adaptive instead of Observables?

Not really, since the file system events I monitor are observables that's why I've been sticking with them, I'm not sure if theres a way I could incorporate adaptive stuff into it

I'll ask Jimmy about it

[nojaf]

There is an Adaptive helper for that (sample), which uses a file watcher under the hood as well. It is interesting stuff, that is all I want to throw in here.

[AngelMunoz]

Hello watcher folks, I hope you have been having a great week so far, here's the next batch of news:

This last set of changes includes most of the major refactoring to eliminate some of the major pains when maintaining this project, the optional values in the core types, to alleviate that I wrote a Configuration module that hopefully should centralize access to the configuration and also a single point for also updating the perla config file

New aditions to the configuration system also allows us to have preference order

Default settings -> Environment Variables -> Config file -> CLI overrides

This also means that perla should be able to run without a config file as long as one has an index file and an src directory :)

While the environment vars change is not enabled yet we can easily support that once we settle which (and if we want) fields to allow being set from env vars, that will likely be used for feature flags at some point.

The first major breaking chances for the config file are in, I've sourced some of the options to be top level ones like runConfiguration (production/development), moved the env file options also to be top level and introduced a few new ones like dependencies and devDependencies!

This change will allow you as a consumer to load dependencies that work with browser extensions like react dev tools or similar yet they won't be there when your production code is built

The FileSystem module is also now the central point for File/directory operations, While this was the goal behind the Fs module in previous iterations, the file system operations were still scattered all over the codebase, this should be in better shape now

The Scaffolding module as well is now self contained to all of the templating operations these may have broken while I did the refactoring, but with the introduction of UMX to the code base I will be able to ensure that I'm not confusing magic strings all over the place the functionality should not change at all so I will have to do the due testing in time.

We moved on from Argu to https://github.com/JordanMarr/FSharp.SystemCommandLine, which offers a different way of parsing CLI arguments, the main reasoning behind it is to also leverage tab completitons, a more customizable CLI for users, and the integration to IHost and some DI utils which may be quite useful within the aspnet server while the commands have been ported, We still need to ensure these commands work better than before

There's still pending refactoring in the following modules

• Fable
• Esbuild
• Server
• Build

Fable

I don't think the Fable module will have significant changes other than allow passing the source maps flag to the fable command and to accomodate to the previous optional settings that should be set this time.

Esbuild

Similar story to the Fable module, it is already pretty self contained and works nice, what could happen here is that we may remove existing compilation functions in favor to create an in-source Esbuild plugin for the Blessed types (JS, TS, JSX, TSX, CSS) but that will be after the virtual file system and plugin stuff is introduced after the refactoring efforts are done.

Server and Build

These two will be the last and are the most critical modules to get right as the premise of Perla lays in them they will be reworked after the new virtual file system and plugins work is introduced in the code base

The plan is to be able to leverage the mounted modules with the zio library to have a better path integration with both source code paths and server paths

The idea is that once the virtual file system is correctly mapped, we'll run each existing file in the mounted directories through the plugin list this in turn should leave us with the end products HTML/JS/CSS which we will process with esbuild in the end to generate a single bundle of JS/CSS and to emit the index file with the correct import map

At dev (or also reffered as perla serve) time we'll do the exact same and the files should be ready to be served by the aspnet app, each time a file changes we will be able to fire of an event either with observables or with adaptive values (I did speak with Jimmy about it and it might be useful for us as well, thanks nojaf for the pointer) and send that individual file through the pipeline and place it in the virtual file system. This should not introduce any noticeable speed changes which should be as fast as today

And I think that's what I got for today.

An extra note in the breaking chances is mostly in the configuration file not in the apps themselves moving/removing/adding some properties should be enough to fix those in your projects.

[AngelMunoz]

Hello there Folks!

The next batch of changes are in!

This week the focus was on cleaning up internal APIs, ensuring things build/serve as they should, the internal esbuild plugin works and leave things in shape for what comes after v1.0.0

Here is the updates:

• 42 has been finally addressed...

  while the test surface area is big and the most complex parts may not be that testable (bad design skills sorry) there are some tests there that check import map generation, some json parsing (to read from confg and other parts of the system, and most important leaves the testing stuff open for others to contribute if desired

• 59 has also been addressed

  perla.jsonc is basically not needed in disk for perla to work, while we do need it to track dependencies the amount of required stuff inside it has been drastically required

• 77 We added fake globbing to solve this issue

• 79 has landed as well

  I plan to add a test runner for client-side tests and playwright, so this was needed to be done eventually

• 80 has landed as well

• 88 should be solved as well

The first previews will start going out during the next week or two so stay tuned

This includes support for plugins!

once the packages are out, I'll let you know

that's it for the meantime, I'll see you in the next one!

[AngelMunoz]

Okay Folks! It is time for v1 pre-releases otherwise I will never get feedback and I will never keep it going because of not enough motivation to finish the testing stuff and we'll go into a vicious cycle

v1 pre-releases will hit NuGet soon!