parseString is documented but not on public API

Am I missing something? The README.js mentions a parseString() function in the public API, but I can’t actually use it:

const editorconfig = require("editorconfig");
console.log(typeof editorconfig.parseString);   // expected: function, actual: undefined

Are there plans to expose this on the public API? (I would love to see it out there and am happy to write a pull request if it would be accepted.)

[jednano]

I think as long as that strategy is only applied for ESLint settings it should be fine. Feel free to submit a PR.

[platinumazure]

@jedmao I’m writing a plugin for ESLint, which is a JavaScript linting tool. This plugin will read .editorconfig files and convert (a subset of) the property keys/values into ESLint stylistic rule configurations. This would allow users to simply use their .editorconfig for configuring ESLint’s stylistic rules (where there is a clear equivalent in .editorconfig).

The exposed API methods are more suited for editor integrations, where I supply a file path and the editorconfig core code will traverse up from that directory and read ancestor files. I’m going the opposite direction-- from the top down, and I need to read all subdirectories for all files to create my result.

Usual use case: Combine ancestor .editorconfig files to determine expected editor configuration for one file

My use case: Read all .editorconfig files in a project and effectively generate a top-level .editorconfig-like structure that takes nested .editorconfig files into account

Example: If I have a top-level .editorconfig file that applies to **/*.js and has some rules, and then I have a nested .editorconfig in tests/specs that applies to **/*.js and has some overrides, I would want to generate a structure similar to the below:

{
    "**/*.js": {
        "indent_size": 4
    },
    "tests/specs/**/*.js": {
        "indent_size": 2
    }
}

As far as I can tell, I just need to read each file, call parseString, and do my computations.

I was wondering about parseFromFilesSync, but it looks like that API still requires a single file path (i.e., the single file we assume the user wants to edit). In my case, I would be calculating this for glob patterns rather than individual files and all I need is the ability to parse the .editorconfig into the JS object.

Hope this makes some sense. If there’s a better way to do this, I’m all ears.