Transition to Javascript API

[domluna]

ref #5

Apparently using the JS API makes this much faster and has more capabilities in general.

[saschatimme]

I took a stab at converting this to the JS API over at my fork: https://github.com/saschatimme/julia-format

This is not a one to one conversion from the existing implementation. Instead this now requires that users have a format folder containing a Project.toml and format.jl script. This is more aligned with the Documenter.jl workflow and has the advantage that it is easy to run the exact same version of JuliaFormatter as it is use in the action.

I converted one of my packages to this workflow: https://github.com/saschatimme/MixedSubdivisions.jl/tree/js-format

Let me know what you think about this :) If you like my proposal I will open a PR.

[domluna]

Thanks for doing this!

Why not just have the installation and format call as part of the .yml workflow file. I think in the case of Documenter the folder structure makes sense:

1. make.jl can get quite sophisticated, so a script makes sense.
2. the docs/ folder is a very convenient place to place your docs

There's probably more reasons, but, in the case of formatting we just install the package using Pkg; Pkg.add("JuliaFormatter", version=...) and run format(...). I don't think we need a folder structure for that.

[saschatimme]

Ok, let me try to come up with your suggested version. One question though, do you want to keep the args field and the bin version or should we rather have one field for each option to format. So a field verbose, margin, etc. Any thoughts?

[saschatimme]

Maybe this is an orthogonal discussion to the switch to the JS api but I think there should be an official configuration file. See for example the prettier docs https://prettier.io/docs/en/configuration.html

If you have a repository with multiple contributors it can otherwise become tiresome to explain again and again with which options to run the formatter. If this is hidden in some Github configuration file then it is not discoverable. Also I think for editor integrations this should make it easier to respect custom configurations.

[domluna]

Ok, let me try to come up with your suggested version. One question though, do you want to keep the args field and the bin version or should we rather have one field for each option to format. So a field verbose, margin, etc. Any thoughts?

There's no reason to keep using the args thing in this case. I only did it that way before because that's the interface for bin/format.jl. If we can call the format function directly we might as well just call format with kwargs.

format(
    paths...;
    indent = 4,
    margin = 92,
    overwrite = true,
    verbose = false,
    always_for_in = false,
)```

[domluna]

Hmm, maybe we could have a workflow example for both? My suggestion being a lightweight version of yours. You can make a case for which either would be preferable.

[domluna]

@saschatimme can you make a PR. I'd like to explore this approach.

[saschatimme]

I am busy this week, but I hope to get a version working during the weekend. However, if you want to try this before feel free to just take my code :)