Working on reading static files from fs instead of using include_str
for debug builds only. Does anyone know of a way in Rust to load a file from a path relative to the source file, similarly to how include_str
works?
I found the file!()
macro, but I would also need the absolute path to the directory containing the cargo.toml
, which I'm not sure how to get.
This is for PR #5375
Are you loading files that are relative to the directory of the roc repo? If so, you can use the env var ROC_WORKSPACE_DIR
to get the directory of the roc repo.
here's an example https://github.com/roc-lang/roc/blob/a6ffc4aed0f653c50b3ed5208224babd55771c68/crates/compiler/uitest/src/uitest.rs#L33-L37
Ah! I think that's what I need!
Are there any documented goals/non-goals for docs generation? I'd like to jump in and help with those as I have time, but I want to make sure I'm working on what's important, and that I'm not inadvertently changing things that were intentional choices .
Here are some Goals I've gleaned from the various discussions here:
Here are some things I'm guessing you want:
Some things I'm not sure about that could impact UX:
Thanks in advance for your input!
Here are some Goals I've gleaned from the various discussions here:
Provide a good experience without JS. Provide a better experience with JS. Generate documentation that loads fast and is inexpensive to serve.
Here are some things I'm guessing you want:
High accessibility Mobile-friendly (I can't be the only one who reads package docs on the toilet, right?) Light and dark modes per user preference.
This is all good, do note that we already have dark and light mode based on the OS preference but I think a toggle would be good as well.
Do we want both package registry search and module search within a package?
I've personally never wanted to search registry packages when I'm viewing docs for a specific package, let's leave it out until there's demand for it.
Do we still want to move toward the visual style provided in the mockups in #3274?
It's a good looking design but I would:
yeah I agree with all that, although I'd note that if we have a light/dark toggle, I'd want it to work without JS (I've seen things like that done using hidden radio
inputs and clever CSS selectors based on value=checked
) and to be very small and unobtrusive, since we already change it automatically using the system light vs dark mode
worth noting that @Luke Boswell already did a bunch on styling, so I'd chat with him about the changes he made
I forgot that mockup issue was still open (I just closed it) - so I think if there are any ideas in there that seem good to incorporate, seems worth discussing, but I don't think we need to go exactly for that mockup now that Luke already made a bunch of improvements!
I didn't realize it was already set based on prefers-color-scheme
, so having a switcher seems like a lower priority than some of the other things I could work on, such as adding an index.html
for packages or moving the search to the top.
I haven't touched it in a while, I was trying to get the styles for docs, examples, the tutorial and website to all align and use the same stylesheet. The idea was to make it easier to bring them all together on the website, and have the same visual style. I spent a fair amount of time getting colours for syntax highlighting which worked well for accessibility and light and dark modes. I don't think I changed the purple colours.
There has also been a number of design evolutions since that issue, there isn't a design guiding everything as far as I know.
I think the goals you've derived look good.
I guess my inclination at this point would be to focus on functional and quality of life improvements, since I wouldn't be surprised if there was a visual language/branding pass over everything as Roc approaches a 1.0 release (I dunno, just guessing).
@Luke Boswell , Maybe I could mention you in my PRs to keep you in the loop?
On that note, I think I have successfully generated an extremely basic index.html
for packages:
Screenshot-2023-05-09-at-10.41.31-PM.png
It's not much, but at least it will eliminate those 404s. Ok If I open a PR for this?
absolutely, thank you so much! :smiley:
love the incremental improvement, and of course it can always be improved further in future PRs
Happy to assist :grinning:
#5391 Ready for eyeballs :)
Last updated: Jul 05 2025 at 12:14 UTC