Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yesod-bin: make yesod devel watch extra files for changes #955

Closed
cdepillabout opened this issue Mar 14, 2015 · 12 comments
Closed

yesod-bin: make yesod devel watch extra files for changes #955

cdepillabout opened this issue Mar 14, 2015 · 12 comments

Comments

@cdepillabout
Copy link

yesod devel doesn't pick up .hamlet files that are not directly referenced from Haskell files. For my personal blog, I create some handlers with Template Haskell. The Template Haskell adds the calls to widgetFile. The actual Hamlet files I am using are not hard-coded anywhere in my Haskell files.

yesod devel will only force a recompile for changed Hamlet files if it sees they are being used from the Haskell files. Hamlet files added through Template Haskell (like I am doing) do not get noticed by yesod devel.

Is there some way to make yesod devel watch extra files for changes (and then re-run cabal build if it finds any)? I hacked around it in the following commit by hard-coding the files I want to be watched, but it would be nice if there was a better way to do this:

cdepillabout@ccdc46a

Is there a reason that yesod devel doesn't do the stupid thing and just watch all .hamlet files for changes? In the current project I am working on, there is never a time when I have .hamlet (or .lucius, .julius, etc) files that I don't want yesod devel to watch.

Do other people have projects where there are many .hamlet files that are not referenced from Haskell files, and where these .hamlet files are frequently changed?

@mgsloan
Copy link
Contributor

mgsloan commented Mar 14, 2015

Is there a reason that yesod devel doesn't do the stupid thing and just watch all .hamlet files for changes?

Yup, this is what I did in my turbo-devel tool. You just provide a list of filepath regexes, and all matching filepaths are watched. While this isn't quite as automatic or precise as yesod devel, it has the advantage of being transparent and configurable. As mentioned here, If there's demand, I can clean turbo-devel up a bit (mostly removing some application specific stuff), and put it up in a repo.

@snoyberg
Copy link
Member

The reason yesod devel got this incredibly complicated logic was because of the Lucius and Julius files. In those cases, it would be a major burden on developers to have to recompile every time one of them changes. However, it caused lots of confusion for people when variables were added and the recompilation wasn't automatic.

I suppose we could consider doing the stupid thing for Hamlet files, I don't feel strongly on the subject. Perhaps some others want to weigh in here?

@wolftune
Copy link

I think it's unfortunate that yesod devel doesn't pick up changes in .cassius files typically. I'd like to see it recognize all .hamlet changes. Ideally, it would recognize that something like .cassius shouldn't have to recompile Haskell files or anything, just update the CSS…

@geraldus
Copy link
Contributor

@wolftune I guess this is not as easy as it seems. What about interpolation? If you add something like

##{myAwesomeElement} 
    font-size : 3em

how compiler should update Css file without recompilation?

@wolftune
Copy link

I don't really mean no recompiling, I guess somehow the whole system should know that only this text area needs to be updated and not redo lots of other math that was already done. I suppose this probably goes into GHC or something beyond Yesod… I don't know, I'm no expert.

@wolftune
Copy link

Gosh, I'm not sure why I didn't realize this, but it looks like I can save things in .cassius files and they simply show up when I reload the website without yesod devel even restarting!

I'm not sure at one point this breaks, but I feel silly, I think I actually believed that I needed to make yesod devel restart in order to see .cassius changes. I think the real issue is that I hadn't (don't?) trust that I've got the final results for sure until it recompiles, but I can indeed see simple style changes right away…

So, at least some of my comments here were mistaken, although some level of file recognition seems to remain per the original ticket…

@cdepillabout
Copy link
Author

@wolftune, my original complaint was about how .hamlet files are handled.

It seems like yesod devel looks through the source of all your Handlers to figure out what .hamlet files are being used. This works well most of the time, but I'm adding widgets (including .hamlet files) programatically using Template Haskell, so yesod devel doesn't pick up on changes automatically.

It would work better for me if yesod devel didn't try to figure out what .hamlet files were being used, but just recompiled when it saw a change in ANY .hamlet file.

Although maybe there are people who have a lot of .hamlet files that are often being updated, but are not actually used by any Handlers? It's kind of hard to imagine someone being in this type of scenario.

@snoyberg
Copy link
Member

Interesting coincidence, I was just researching a different problem and realized that there's a much better solution to the issue here. Instead of trying to guess dependent files, we can just ask GHC via the .hi file, by running ghc --show-iface on the relevant files. We should use this in the new yesod devel (pinging @urbanslug).

@gregwebs
Copy link
Member

You can also try using hamletFileReload in development, but its templating support is much more limited.

@geraldus
Copy link
Contributor

@wolftune note that this is not true for julius files changes, usually I have to restart yesod devel to pick up latest changes.

@snoyberg
Copy link
Member

This is planned for the new yesod devel in the GSoC project, closing in favor of that.

@urbanslug
Copy link
Contributor

I am in favour of this, yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants