hougesen / mdsf Goto Github PK

https://github.com/inaka/elvis

https://github.com/facebook/usort

https://blue.readthedocs.io/en/latest/

https://developer.hashicorp.com/terraform/cli/commands/fmt

https://github.com/WhatsApp/erlfmt

This tool has some feature in common with you

https://mdformat.readthedocs.io/en/stable/users/plugins.html#code-formatter-plugins

Maybe it could be mentioned in the README.md

I don't know if you knew it and if it was one of your inspiration or not

Your code is a markdown code snippet formatter. That's the project purpose OK.

Your code is formatting block that could be invalid.

So your code is somehow also a linter, as you are able to know when you are facing an error when formatting a code block.

In debug mode I can see the code that are invalid (or with an strafe, I'm unsure)

What about reporting something like a warning aside file names to say you face x errors when processing a file.

https://github.com/dotenv-linter/dotenv-linter

https://github.com/NixOS/nixfmt

Your code launches formatter on each code snippet.

Based on what I can see the code is extracting the code snippet, look for the header, then call the formatter according to the one available

I was struggling with some files formating that were taking 700s to be formatted.

When I moved the file in /tmp/ it was instant.

I used strace to identify the issue. At first I thought the code was looking for tons of files because of a bug in discovering foldes.

It appears the code calls npx to launch formatter such as sqlformatter

npx relies on node_modules, so when the files were in a repository that needs a private npm registry, AND my VPN is down. It will try over and over to reach the npm registry that cannot be reached.

When I switched my VPN on, the mdsf was able to format instantly.

TL;DR; This should be considered as a source of problem. I think you should implement at timeout setting (that maybe configured) this was when formatting a file you could stop processing and inform a user there were an error.

https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-format

https://github.com/google/yamlfmt

https://github.com/dzhu/rstfmt

I love your tool idea.

I can see you are actively working on it, so first of all, thank you !

Here are the kind of replacement I noticed

# title

Let's play!

Have some fun...

I like "mdsf"

| Field            | Description            |
|------------------|------------------------|
| foo              |   foo field            |
| bar              |   bar field            |

```shell
ls
```

will become

# title

Let’s play!

Have some fun…

I like “mdsf”

|Field|Description|
|-----|-----------|
|foo|foo field|
|bar|bar field|

```shell
ls
```

The table formatting is broken. It will render OK in markdown, but the text was altered.

You might not notice at first but it replaces:

• ... (three consecutive dots) into U+2026 … HORIZONTAL ELLIPSIS
• simple quote by U+2019 ’ RIGHT SINGLE QUOTATION MARK
• double quoted text by text surrounded by:
  • U+201D ” RIGHT DOUBLE QUOTATION MARK
  • U+201C “ LEFT DOUBLE QUOTATION MARK

I would expect the code to only apply changes on the block quotes

shfmt is made for formatting script, definitely.

```shell
#!/bin/env bash

    date
```

But shell block quote in markdown is not ONLY about that

Yes, this would be valid

```shell
  cp   foo    bar
  touch   foo
```

But the alternative syntax used in many markdown linters is this one

$ command
result

So this

```shell
$ date
Tue Apr  2 23:54:37 CEST 2024
```

Please note this one is sometimes refered as console

```console
$ date
Tue Apr  2 23:54:37 CEST 2024
```

```console
foo@bar:~$ whoami
foo
```

So your script will try to format things that are not always script.

Following #158 idea

Another interesting idea could be to be able to report when our code found block code you could have checked/formatted but you couldn't because the parser is not available.

My point is the fact someone may install your tool, but nothing else.

It will launch mdsf on his markdown files, but it will provide nothing.

So maybe, something you could report at the end as a warning.

https://github.com/dlang-community/dfmt

https://github.com/Koihik/LuaFormatter

https://github.com/kamadorueda/alejandra

By creating #161 I found this interesting resources:

I think it's the list of "fenced blockquote" known by GitHub Flavored Markdown

https://github.com/github-linguist/linguist/blob/master/lib/linguist/languages.yml

```go
var err = errors.New("dddd")

type Whatever struct {
     StartAt                time.Time  `json:"start_at"`
                End                time.Time  `json:"end_at"`
    Delete bool `json:-"`
}
```

golang can only be formatted with tools if the file is valid.

So if the linting doesn't work you can try to add this to the begining of the file

```go
package main

// REMOVE ANYTHING ABOVE THIS

var err = errors.New("dddd")

type Whatever struct {
     StartAt                time.Time  `json:"start_at"`
                End                time.Time  `json:"end_at"`
    Delete bool `json:-"`
}
```

mdsf will then be able to format like this

```go
package main

// REMOVE ANYTHING ABOVE THIS

var err = errors.New("dddd")

type Whatever struct {
	StartAt time.Time `json:"start_at"`
	End     time.Time `json:"end_at"`
	Delete  bool      `json:-"`
}
```

Then if you trim the code then

```go
var err = errors.New("dddd")

type Whatever struct {
	StartAt time.Time `json:"start_at"`
	End     time.Time `json:"end_at"`
	Delete  bool      `json:-"`
}
```

It would be a more fail proof hack but quite an hack

gofmt requires the snippet to include a package.

• Single line
• Multi line

It would be interesting to be able to see the formatter that is running on each file

Of course, it would be only something to ask on demand.

maybe like a -v that inform that block from line X to Y is sent to prettier/shfmt.

with a -vv the information would be more details with the block content before calling the method, then after/ but also the exact path of the formatter used.

it could also be a kind of log level info/warn/error/debug

Embedded language formatting must be turned off https://prettier.io/docs/en/options#embedded-language-formatting

https://csharpier.com

Here is the documentation of an http request

```http
POST /login HTTP/1.1
Authorization: Bearer bar
Content-Type: application/json

{
"foo": true}
```

Here is a reply

````mardown
```http
HTTP 200 OK
Content-Type: application/json

{"success":      true  }

```

But it's not limited to json replies. It could return HTML/XML

It's a very used pattern in API documentation

The code snippets are badly indented on purpose.

https://github.com/PHP-CS-Fixer/PHP-CS-Fixer

Either if files are processed and reformatted or not.

https://github.com/avh4/elm-format

https://github.com/fables-tales/rubyfmt

https://github.com/facebook/ktfmt

https://github.com/sql-formatter-org/sql-formatter

https://laravel.com/docs/pint

Mix format is a formatter for elixir

Here is a content that is wrongly formatted

This is the content of a markdown file

```json
{
        "foo": "bar",
        "user_id": "2313",
        "scope": ["internal"]
}
```

This is the content of a markdown file

```json
{
  "foo": "bar",
  "user_id": "2313",
  "scope": ["internal"],
}
```

The extra comma at the end of the list lead to an invalid json

Here is my mdsf.json

{
  "$schema": "https://raw.githubusercontent.com/hougesen/mdsf/main/schemas/v0.0.2/mdsf.schema.json",
  "json": {
    "enabled": true,
    "formatter": [
      [
        "prettier"
      ]
    ]
  }
}

prettier 3.2.5 is installed and work well.