Improve README and Setup Tasks to support developers wishing to develop without a deck

[TrainDoctor]

• Provide instructions for setting up Decky with a deck and how to build/send your plugin to the deck for testing
• Provide instructions for setting up Decky on a linux development environment and how to build and or test the plugin locally.
  • Improve language and template's support for deploying to a deck without using the CLI tool
    (CLI tool will ultimately be used for distribution of a plugin but is not needed for quick development).

Looking for more feedback from devs on how this can be improved outside what I've stated below. This issue will serve as a discussion for said desired improvements as well.

[codetakki]

This might already be covered by the "Create instructions".
But having a good "Hello world" example always helps me get on track when working in new environments.

So step by step instructions of getting a first edit onto the steam deck, and making small changes would be very useful.

[AkazaRenn]

The most trouble I met during setup was how to find and start the tasks mentioned in the README. It would be good to give some suggestions on which extension to use, I am using https://marketplace.visualstudio.com/items?itemName=spmeesseman.vscode-taskexplorer

[XanderXAJ]

Probably like everyone else here, I had to figure out a lot of stuff to get properly started. Since taking those first steps, my goal has been to make builds and deployments of my plugin as simple as possible and ideally without prompts for passwords and configuration.

After forking the plugin, I extensively re-wrote the README to suit my needs. Please do read through it -- especially the Development section -- as it contains both build and deploy instructions along with a number of debugging tips. You're welcome to copy and adapt it for the community's needs (and I'm happy to help out if you want). 🙂

Since it is my plugin, I did also make it opinionated. Here are a few thoughts and changes I made to my plugin and build tasks for your consideration:

• I've only been testing on Deck and haven't made any instructions/consideration for developing locally.
• I'm developing on an Ubuntu distro in WSL. Changes should be compatible with pure Linux or macOS but I haven't checked.
• I made the builddeploy task the default since it is a single task that gets everything done. Separating builds and deploys isn't much use in my workflow.
  • It might be nice for the deploy to use rsync or similar since files that no longer exist in the plugin are not removed upon a deploy.
  • @AkazaRenn My README has some hints about discovering tasks -- hopefully it is of help to you. 🙂
• I dislike getting loads of prompts for passwords or configuration and aimed to minimise it. A builddeploy invocation now gives me zero prompts.
  • Since there are no prompts, this could potentially be automated with something watching the filesystem...
• I removed the need for sudo upon builds via this patch to Decky CLI. This saves me needing to type a password every deploy.
  • This patch is not yet available in the CLI's stable releases, so plugin setup will download an older version that needs sudo for builds. 😞
  • I don't need sudo for Docker access since I'm using WSL and Docker Desktop. Other devs may need to use rootless Docker or add their user to the e.g. docker group (and understand the ramifications therein).

[AAGaming00]

I suggest using the watch mode of rollup to build your JS as it builds much faster due to being incremental

[XanderXAJ]

I suggest using the watch mode of rollup to build your JS as it builds much faster due to being incremental

@AAGaming00 Can that be combined with deployments? 😮

[TrainDoctor]

@XanderXAJ I don't have much time myself to integrate the changes you made manually but if you were to submit a PR with generalized changes I'd be happy to review those and merge when appropriate!

[TrainDoctor]

Unfortunately I no longer have the time to work on this aspect of the documentation as I would like. If plugin developers are willing to contribute some generalized knowledge to our wiki then we'd be happy to accept that. Marking as middle priority as this work should eventually be done.