markdown-link-check

markdown-link-check copied to clipboard

It would be ideal for the use case of CI with secrets if JS could be used for the config, assuming it returns an Object that is in the shape of the config options.

Could you tell me more about your use case? MLC is already available as a JS function that you can call from any JS script and why not in your CI using Node.js. The configuration for MLC can then be passed as a JS object to the function (the options param). Is that enough or is that that you also need all the options to be configurable through this option object?

@NicolasMassart specifically, I want to use the CLI --config flag and be able to pass a .js file that returns an Object that would be the same as the JSON Object that it currently looks at. This would allow me to programmatically set variables that are specific to my CI environment rather than having to write the config file in CI.

Why not generate this JSON from your JS script in your CI job then use the generated JSON with the --config option?

I could but having to generate the file, write it to the filesystem, make sure that it'll also exist locally when not running in CI / write it in that case, and actually testing/debugging it in CI is a lot more work for users than just writing a JS file that returns an object.

The issue I see is that STDIN is already used for MD input and then can't be used for a JSON config stream input. Can you describe what you would like the command line to look like please?

NOTE: It seems STDIN is not used for MD direct input as described in #67 but only to input list of files or files links using STDIN. But the issue remains the same here, STDIN is already used.

A common pattern to solve this is to use ENV variables. What would you htink about giving the option to set the config as a JSON string in an env variable? This would solve your CI issue doesn't it?

Theoretically yes, environment variables for every single setting would solve this problem.

Going to be totally upfront: I don't understand the stdin issues enough to meaningfully be able to provide input on them.

Going to be totally upfront: I don't understand the stdin issues enough to meaningfully be able to provide input on them.

Me neither, I have to dig in this a bit.

Hi @ll,

there is one potential security issue where it could make sense to have a more dynamic configuration and this is when someone has to put credentials in the config stored in a repo. But instead of injecting the entire config as env variable, why don't you just implement a special replacement command for env vars like {{env.<env_var_name>}}. E.g:

{
  ...
  "httpHeaders": [
    {
      "urls": ["https://example.com"],
      "headers": {
        "Authorization": "Bearer {{env.EXAMPLE_COM_TOKEN}}",
        "Foo": "Bar"
      }
    }
  ],
  ...
}

I think this is super easy to implement, easy to understand and would give us enough flexibility.

Best, Chris

For what it's worth, that was the exact use case I had.