-
Notifications
You must be signed in to change notification settings - Fork 292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite Fable.CLI #3725
Comments
|
There 2 others situation where we want it to be removed:
|
I somewhat disagree with 2, the Just place everything under |
To reword to something more neutral, I am going to say Case where we want to invalidate the cache:
For the |
I also feel like the cache means different things in different contexts. It would be beneficial to be able to be explicit about this. I might make wrong assumptions about things as well. There are multiple aspects here:
The cache key for all these things will also be a set of different combinations. |
We should consider give a try to using simple-exec instead of our custom wrapper on top of I know that in the past, Alfonso wanted to minimised the number of dependencies Fable but I think if it can simplify our code and make it more robust we should consider using dependencies. Like we did for the logger for example. Speaking of the logger, I propose that the new CLI have this option
|
Having some additional dependencies for In Fantomas we have a few dependencies for the cli tool but are very strict about having none for the library ( I'm in favour of a wrapper of For logging, I would stick with the verbosity levels of MSBuild (q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]). Ok, maybe not have |
Thanks for sharing your experience.
I don't know about CliWrap, I will have a look at it.
Makes sense to me 👍 Before starting to rewrite Fable.CLI, I will make a proposition for how the CLI tools args/options could be done. Reason for that is at the moment all the options are top level but it doesn't make sense for all the language to have access to them. This means that we will have a breaking changes in how the CLI works, but hopefully it will allow for a better user experience / discoverability of the options. |
Here is a first draft of a CLI design to start the discussions: First thing which denote from the current CLI is that I am proposing to handle the target switch as a subcommand instead of a flag. This will allow us to offer better help messages which are specific to each target.
Questions:
|
As someone who's been using Fable mainly to turn F# into JavaScript, it feels like a step back having to type Why not let us set this up in the fsproj file? If it's not set, how about using an environment variable to pick a default? Like, if you're all about Python, you could just set an env var once and be done.
|
In the current implementation:
Personally, I don't like
How would you write the description of this flag as it is dependant on the target.
I do prefer the flag myself too.
Personally, I am not a big fan of env variable for controlling such behaviours. It is easy to forget that you had this env variable setup and wonder why you don't have the default behaviour in a new project. It is kind of like the same as when using global tools or local tools. IHMO we should always use local tool because the version wanted is linked to the project and the computer. Allowing to use I am not familiar with If we allow multiple source of configuration in what order should it be? from highest to lowest priority
True but the problem is that Fable is not anymore just a JavaScript transpiler and needs to adapt to that. We should provide a similar experience for all the targets. It is the same with Fable.Core who needs a rewrite because ATM JavaScript API are leaked to others target instead of being sandboxed/scoped. Perhaps, we could consider And if the users wants to see the options for Another solution is to structure the help message differently by flattening it:
And saying that |
Yeah, that makes sense.
Could you elaborate on that? How is modifying the extension impactful for any particular target?
There is reality and there is perception. I would be in favour of organizing a twitter poll with the following question: "What do you transpiled F# to?"
If the overwhelming majority is still in the
Yes, of course, you want a local tool but that doesn't mean that all your different repositories will target a language. As I suspect, JS will be a good default here. Python folks could override this with an env var, if they only do Python. I see this similar to how the I would go for a default command ( If you specify a specific target like
Yep, if we were to settle on something like |
Please note this is only a personal opinion/preference. I have to agree somewhat with @nojaf that if the majority of use cases are for specific language it should be the default. But it would be really nice if we don't introduce yet another new environment variable or MSBuild property that people need to remember or look up every time. My strong preference is for a simple
About the difference between
Again, this is only a personal preference, but I will side with the majority. |
Oh yes for sure, anything related to how we expose an API or craft a CLI (probably worst for a CLI) is a personal opinion/preference. I hope, I didn't appear as trying to force something in this discussion. I am trying to gather feedback and to come up with a collective decision. My way of thinking here was to go with the most "strict design" at first to see the limitations / UX from it. And as seen, it leads to severals questions and probably needs to be made more pragmatic related to Fable target audience and usage. I based the proposition on Command Line Interface Guidelines I am now thinking that we perhaps indeed keep And then having The reason for using For example:
It would also allows to expose target specific flags. For exemple, I suppose Regarding different source of configuration, I think it could be a nice addition even if like mentioned by @ncave. It means that we need good documentation for it. To follow Dotnet/MSBuild order we should do: From highest to lowest priority
Click to see - How I tested this behaviourI checked against a Tested by having a <?xml version="1.0" encoding="utf-8"?>
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<PackageVersion>1.1.0</PackageVersion>
</PropertyGroup>
<!-- .. -->
</Project>
That's great news then 👍 But in my mind if we go this path, it would not be limited to just the target but all the options: Pseudo XML, it is just here to illustrate. <PropertyGroup>
<FableGroup>
<FableLanguage>javascript</FableLanguage>
<FableOutputDir>../fableBuild</FableOutputDir>
<!--
In theory we should be able to use MSBuild variables too
<FableOutputDir>$(MSBuildThisFileDirectory)/../fableBuild</FableOutputDir>
-->
<!-- ... -->
</FableGroup>
</PropertyGroup> |
IMO it all depends on who we consider the largest audience for Fable. If it's web developers, IMO we shouldn't add more MSBuild properties or ask them to be fiddling with F# project files too much (besides simply including the F# code files in the project). It's already probably a high bar for them having to deal with .fsproj files, adding more is perhaps counter-productive. |
That is a really good take @ncave! |
For reference here is the result of the poll: TBH I am quite surprised by the number of TypeScript usage. Regarding Rust, some people commented that they wanted to use Rust but didn't because they didn't know how to interop with existing code / libraries which is expected as we don't have documentation for it. |
For Rust (much like interop with F# assemblies from C#), it probably makes most sense to build the domain logic in F#/Fable and interface it with a native Rust adapter. Or where possible, build everything in F#/Fable. |
Description
Current code of Fable.CLI is difficult to maintain.
We should rewrite Fable.CLI so it is easier to maintain and extends.
Rewrite the CLI parser.
I would like to avoid using Argu as I find that Argu as some limitations in how it allows the CLI to be structured.
Depending on the time frame, I am interested in exploring using function composition to describe the CLI. It is a similar approach to how Thoth.Json and Fable.Form solve their problem.
elm-cli-options-parser could be an inspiration for the exposed API.
This would be released as an independent library.
Functions / API should do one thing at the time. For example, currently when we try to retrieve the path of the
fable_modules
folder, it is not just giving us the path but also tries to delete / initialise the folder which causes issues when running in watch mode.The text was updated successfully, but these errors were encountered: