Create a cli script so other editors can collect and use results

[mrozbarry]

Just looking briefly at the source, it looks like this is completely coupled to Atom, which is fine, but it means no other editor can use this really neat tool.

What would be interesting is if this were an npm package, that could be used like:

$ npm install -g elm-lens
$ elm-lens ./src/*.elm

And it would send out (maybe json?) information about each function, maybe something like:

[
  {
    "file": "path/to/file.elm",
    "line": 5,
    "name": "nameOfFunction",
    "definition": "nameOfFunction : Int -> Int",
    "externalReferences": [{ "file": "other/file.elm", "line": 72 }],
    "internalReferences": []
  },
  // ...
]

Not sure you'd need all that information, and maybe you could scope things a little better to make the json output much smaller, but that's the general gist. From there, you could pipe it to a file in unix like elm-lens ./src/*.elm > elm-lens.json, or from an editor, consume that json and show the appropriate information in the editor.

Haven't looked into the source code enough to know what sort of effort this would be, but it will satisfy 100% of the other issues that will crop up of "please support editor x."

[mbuscemi]

I had added editor abstraction to the roadmap here: https://github.com/mbuscemi/elm-lens/blob/0.2.0/README.md.

I would like to avoid abstraction work at this stage because of the well-known software development problem of premature optimization. What I have released is only a small portion of Elm Lens's planned functionality, and I think that trying to tack another editor on now would slow me down more in the long run. Once I have developed Elm Lens's major features, I'll be able to approach VS Code (and any other editor that supports JavaScript/Node-based plugins) with a much more coherent strategy for encapsulation of editor details.

Elm Lens is currently not too far off from that goal. I have the "workspace", "project", "navigation" and "text-editor-facade" abstractions that wrap editor-specific calls in a generic JS class. And the Elm part of the plugin is, by its very nature, completely decoupled from the editor, and this, I imagine, can be shared wholesale by any editors. The JS-layer abstraction is not perfect, but to reiterate, I'm wary of trying to perfect it at this stage. I know this will be frustrating for people who would like to see Elm Lens in their favorite editor now, but I think that by taking my time, I will be able to ultimately provide the best experience in those editors when I do execute on that implementation.