Supply pre-built assets for easier packaging #493
I would like to make a FreeBSD port (package) of your nice project. Unfortunately one step in the build process involves using npm to build some assets. Node.js applications are notoriously hard to package because of the large amount of dependencies (all of which need to be manually kept track of and mirrored for reproducible builds) and that alone already makes it very hard for me to do the port.
Would it be possible for you to ship pre-generated asset files with the releases so I don't have to figure out these NPM problems? This would tremendously simplify the porting process. Apart from the assets, it seems to be just a straightforward Go project. Even the
The text was updated successfully, but these errors were encountered:
Thank you for taking an interest in this, @clausecker! We'll be happy to promote this package once it's available.
To your question, would the assets included in our official releases work? Or would you need them to be included in the repo? Ideally, we'd avoid committing them, so we can also avoid issues with things getting out of date.
Otherwise, glad to hear things are pretty straightforward. I would definitely like to switch us to
Lastly, just for some house keeping, I'm going to close this since it isn't a bug report. We can continue the discussion here, but in the future, our forum is the best place for these kinds of discussions!
The assets included in the official releases would indeed work, but it's more hassle and requires a lot more data to be downloaded. A tarball with just the generated CSS files would be a good solution.
A common strategy is to have a release branch with generated assets checked in that is merged into every release and has release tags. Thus, the assets only need to be updated on release and don't generate spurious changes during development. But I understand if you don't want to do this busywork.
Another difficulty I noticed is that getting good UX for the configuration is hard. Ideally, we would like to have files spread over three or four directories:
Also, the working directory should not matter as that makes things harder when running the service as a daemon.
But right now it seems like most paths are hard coded and writefreely will only look for these files in the working directory. This makes things a bit harder for the port and forces us to break conventions (such as not mixing user-generated files with package-supplied files). I understand that some (but apparently not all?) of these paths can be overridden in the configuration file, but there is only one such file and if we have the user generate a configuration interactively, the user would have to be instructed to enter the right path which isn't very good UX.
Ideally there would be some sort of mechanism to have a configuration file (e.g.