You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 find0.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?
The text was updated successfully, but these errors were encountered:
bentefay
changed the title
Support symbolic links
Support for symbolic links
Jun 24, 2020
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:
In this example,
src-common
is a symbolic link to elsewhere in our monorepo. Ourelm.json
then contains: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 thesource-directories
ofelm.json
. In our case, this is ignoring thesrc-common
entry.I have managed to trace this issue down to the specific version (
0.2.7
) of thefind
npm package thatelm-analyse
is using.The problem is with the call to
find.fileSync(/\.elm$/, sourceDir)
ints/util/file-gatherer.ts
ofelm-analyse
. Unfortunately, the implementation offind.fileSync
in version0.2.7
is ignoring symbolic links (unintentionally). This issue is fixed infind
version0.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 thefind
folder fromnode_modules/elm-analyse/node_modules
to force it to use0.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?The text was updated successfully, but these errors were encountered: