elm-analyse icon indicating copy to clipboard operation
elm-analyse copied to clipboard

Support for symbolic links

Open bentefay opened this issue 4 years ago • 0 comments

Hi there! At my company we're experimenting with reusing elm files between two elm applications. Our approach involves each app including a symbolically linked directory that contains the shared files. Using a symbolic link makes editing the common files easier, as the various IDEs we use can then be focused on just the relevant files for an app, including the shared files, and the same approach works for Typescript files (for our ports and web components).

Our proposed folder structure is something like:

- ui
  - src
    - <app specific elm files>
  - src-common (symbolic link)
    - <shared elm files>

In this example, src-common is a symbolic link to elsewhere in our monorepo. Our elm.json then contains:

    "source-directories": [
        "src",
        "src-common"
    ]

This approach seems to be working well, with elm correctly compiling, testing and watching files in the symbolically linked directory. The one problem we are running into is that elm-analyse does not appear to support symbolic links. Specifically, it ignores symbolic links in the source-directories of elm.json. In our case, this is ignoring the src-common entry.

I have managed to trace this issue down to the specific version (0.2.7) of the find npm package that elm-analyse is using. The problem is with the call to find.fileSync(/\.elm$/, sourceDir) in ts/util/file-gatherer.ts of elm-analyse. Unfortunately, the implementation of find.fileSync in version 0.2.7 is ignoring symbolic links (unintentionally). This issue is fixed in find version 0.2.9 (https://github.com/yuanchuan/find/releases/tag/0.2.9).

I have confirmed that this fixes the problem by installing find 0.2.9 in our app, and then deleting the find folder from node_modules/elm-analyse/node_modules to force it to use 0.2.9.

Unfortunately this won't provide full support for symbolic links, as find has the frustrating behaviour that it only follows top-level symlinks and not nested ones. But it would be sufficient for our purposes.

Would you be open to accepting a PR that bumps the version of find and potentially adds tests for analysing files referenced through a symbolic link?

bentefay avatar Jun 24 '20 04:06 bentefay