Skip to content

Support for symbolic links #246

@bentefay

Description

@bentefay

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions