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]

This feels a bit unnecessary.
Any extensions as a string would fit the bill here.
You can always use active patterns in your own code if you want to pattern-match this.
As a plugin writer, I wouldn't see much benefit in this structure.

[AngelMunoz]

Hmm yes, you are probably right I'll consider taking this one out

[nojaf]

If you cannot update this field, I would suggest making a FileTransformRequest and FileTransformResponse type approach to it.

[AngelMunoz]

The idea of these plugins is that they will run at build time and when the dev server starts, a file changes, so I don't necessarily want to introduce something that ties to dev/build time specifically I'd like to have it agnostic

The plugin should be able to run without caring who is calling it at what time, since I will have control when these are called I might as well ensure that the originalPath stays as is even if users modify this value

But! that being said I'd like to know what do you have in mind for that, could you elaborate a little bit more on this please?

[nojaf]

Just something like:

type FileTransformRequest =
   { OriginalPath: string
     Content: string
     Extension: string }

type FileTransformResponse =
  { Content: string
    Extension: string }

Given that you mentioned originalPath should not be updated.

[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!