Features Wishlist

[japhib]

After having some trouble earlier getting this to work, (#21, #22) I've returned to this on a different computer & with node 12 instead of 14 and it works great. Now that I've got this working, there's nothing holding me back from using Love2D more, and I think I'd like to contribute to this library to make it as good as it can be. So, I'm making an issue with a short list of the features I'd like to implement:

• Ability to specify a custom theme at build time, so you don't have to edit the built .html or .css files each time you rebuild
• A "serve" option, where after you build it starts a little HTTP server locally so you can view your output files in a browser
• A "watch" option, where it'll watch the filesystem for changes & rebuild each time it detects one.
• When you run it on a directory, an option for ignoring files (such as the .git folder) and leaving them out of the build

[thomasgoldstein]

Nice, but it might be better to open one issue per feature.

[Davidobot]

I think every single one of these features could be implement with console shortcuts and joint commands.

Not really sure these can or even should be built in.

e.g. The serve option is probably something like love.js... && python -m http.server...

[japhib]

I can open one issue per feature request if that is preferred.

And sure these features can be run with separate commands. But, at least for the serve option, I would argue that if it's something every user is likely to need to do every time they run the tool, and we can provide reasonably common functionality without much trouble, it makes sense to be built in. And I think it's reasonable to expect that every user would want to test their changes in the browser every time they run the tool.

I mainly say we should add the serve feature because the python default server does not provide all the functionality you might commonly want -- for instance, if you want to test the game on Firefox, you have to implement your own custom server that provides the right headers. It also doesn't send the right wasm application type header which puts another error log in the console. Both of these would be trivial to implement as a serve feature with express.

I agree the other features don't necessarily need to be built in if you're trying to keep this lean though. But maybe we could provide reasonable defaults like not packing the .git folder -- maybe ignoring all files that start with a . is the right way to go?