Comments (5)
Hi! Can you show me a concrete example of:
- What your current, painful setup looks like. Both elm-watch.json as well as the input Elm files are interesting. A full GitHub repo for the complete context would be amazing if possible!
- How you envision it could look like with globs.
from elm-watch.
Awesome, thank you!
So you have "type": "package"
in your elm.json. As mentioned in at the end of What elm-watch is not, packages aren’t really supported by elm-watch – only applications are. (I even explored giving an error if elm.json
has "type": "package"
at one point, but it’s a long story.)
The thing here is that I don’t write many packages myself – only applications. And when I’ve written packages, they haven’t been very large. Either so small that running type checking in my editor (with an occasional elm make
without arguments on the command line) has been enough. Or slightly larger, but then elm-test --watch
has been great: Fast enough and I get to know that my package compiles, as well as the tests, and also that the tests pass.
I do have thought a lot about if elm-watch could be used for packages as well, and for a while I even supported "output": "/dev/null"
in elm-watch.json
for that purpose (type checking only). However, I’m not sure even that makes sense – it feels like watching packages is a similar but different thing:
- It doesn’t make sense to have any output, ever. (In your project,
build/*.js
files are still created but are never used.) - It doesn’t make sense to specify inputs. All you need is
elm make
(without arguments) to be run when files change. - The watcher should read
"exposed-modules"
in elm.json to figure out which entry points there are for the package, and followimport
s from there to know which files do and don’t affect compilation. - One might also want to mix watching the package itself, with watching a demo application, in the same elm-watch.json.
So, I don’t know, maybe this it how it should be:
{
"targets": {
"MyPackage": {
"type": "package",
"elm.json": "elm.json"
},
"Cool demo": {
"type": "application",
"inputs": ["demo/src/Main.elm"],
"output": "build/demo.js"
}
}
}
In summary, I have a lot of thoughts around this, but I can’t make up my mind if it makes sense to build something like this or not. One thing that has been great while developing elm-watch is that I knew exactly what I needed: I had worked with Elm professionally for several years, and I knew the pain points and wishes I had from the old Elm setup at work. So I have built it exactly for my own use cases (while still keeping it general enough to be usable by others). Since I’m not a big package developer, packages was down prioritized, partly to avoid scope creep and partly since I don’t know exactly what’s needed for the package use case.
While the above JSON with "type"
on each "target"
might be the right way to do it (not sure), I’m reluctant to adding glob support to "inputs"
as an “easier” solution. That would require another dependency (because I’m not going to implement globs by hand), and I’m very careful with dependencies in elm-watch. Also, everything in elm-watch is designed to not be Node.js specific because I have a dream of writing elm-watch in another language one day that can compile to a standalone binary. So I would have to come up with how to “standardize” which globs are supported etc. And I’m not sure it makes sense to use globs for a real application use case.
Finally: What we do at work is actually generating the elm-watch.json
file (but for a different reason). Our startup script runs something like node generate-elm-watch-json.js && elm-watch hot
. I guess you could do something similar.
What happens now?
- You can generate
elm-watch.json
and call it a day, probably. You’ll use elm-watch in a non-intended way, but it’ll probably work out and be useful for you. - You could also try to make your tests cover all parts of the library and use
elm-test --watch
instead. - Or you could make the demo application cover all parts of the library and use elm-watch for that, type checking the whole library as a side effect.
- There’s also https://github.com/Janiczek/elmid which might be interesting.
- Either way, I’ll leave this issue open to see if others pop up with the
"type": "package"
use case as well. I suspect it’ll take a while for anything to happen though (even if this turns out to be a popular request), because (at least currently) I don’t need this myself and I’d like to spend my time on https://github.com/lydell/elm-safe-virtual-dom. I’m mostly interested in tweaks and bug fixes of elm-watch for the moment – I like the very stable place it’s in right now.
from elm-watch.
@lydell thank you for this very thoughtful reply.
I think the package option sounds really cool. For now I'll follow your suggestion of generating the file. Thank you!
from elm-watch.
I can in fact provide a full repository: https://github.com/unisonweb/ui-core
This is consumed as a "library" via elm-git-install.
Here's the elm-watch.json: https://github.com/unisonweb/ui-core/blob/main/elm-watch.json
from elm-watch.
A glob solution might look like this:
{
"targets": {
"UI": {
"inputs": [
"src/UI/**/*.elm"
],
"output": "build/ui.js"
},
"Code": {
"inputs": [
"src/Code/**/*.elm"
],
"output": "build/code.js"
},
"Lib": {
"inputs": [
"src/Lib/**/*.elm"
],
"output": "build/lib.js"
}
}
}
from elm-watch.
Related Issues (20)
- elm-watch beta: CLI gives https:// links by default in Bun HOT 6
- Running 'example-minimal' in devcontainer wsl2 - not picking up changes to *.elm HOT 2
- Runtime error after build with --optimize HOT 10
- Getting the error `Error: spawn Unknown system error -8` when using Node 18 HOT 9
- Allow overriding the output file for a target HOT 6
- Allow building a file with the hot-reload code inserted HOT 1
- File changes made don't trigger hot reload - WSL2
- RFC: Overhaul HTTPS support HOT 13
- how would you use elm-optimize-level-2 with elm-watch? HOT 2
- Command line is too long error HOT 1
- dynamically specifying output location HOT 6
- using a known hostname but dynamic port HOT 8
- Add output to postprocess arguments HOT 2
- Permission denied when running as root HOT 2
- elm-watch hangs on error HOT 6
- watching through symlinks HOT 1
- elm-watch hangs on error in dependency stage HOT 5
- The port showing as "0" (http://localhost:0) in the terminal when elm-watch is concatenated with the "cat" command
- errors display below <dialog>s HOT 4
- Broken link in the docs
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from elm-watch.