I have two side projects (applications) where the frontend is written in Elm. I’m now finding myself quite often copying files between these projects. Mostly it is either utility functions or “components”, like form elements or other ui things. Both projects use Semantic-UI and so share quite a lot (like dropdowns, password input fields etc).
How can I move those things into a place that can be shared with both projects?
I guess I don’t want to
elm publish something, because after reading
elm publish --help it seems that this is not wanted. I’m not sure whether the package I have in mind will be useful to more people and it might not be a great solution/package.
I hope I didn’t miss anything obvious, and I’m sorry if I did. I searched the internet and found several long github issues and discussions that seem to touch this topic. But I couldn’t follow them very well, so I ended up a little confused. I read many proposals, but I’m not sure what is available now or what is the elm-way here.
Thank you for your help and kind regards
You can add more folders to the
source-directories array in your
elm.json file. So you could have a relative path to a shared place or git submodules to link both projects!
Thanks for your reply. I could add more folders to the
source-directories array. But these folders are then not managed. IMHO this is not practical, as the build gets more complicated. I’ll have to prepare the folders also on travis. It’s too easy to depend on something not well defined. I’d like to see in the build definition, that there is a dependency on
x. That’s why I didn’t consider this as on obvious option.
However, git submodules would mitigate these things. I used submodules earlier (not with Elm code), but I found it rather inconvenient. But that is just me, of course.
I guess, I’ll give git submodules another try then
Thank you! This looks interesting. My use-case is not to have private packages though, but this way I could point to my git url.
I found a similiar project that had some controversial discussions, that was partly a motivation to ask here.
This project purposefully bypassed the constrains around internal APIs. They may look superficially similar but the intent is quite different.
Another thing that might be relevant is that Robin is part of the Core Team.
Thank you for the clarification!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.