chore: ad .devcontainer file e.g. for GitHub Codespaces

[rugk]

This PR may fix #1135

Fixes #1135 ?

Changes

• these are just the files, when you start Codespaces, i guess from composer

ToDo

• check whether that is okay
• if not, cleanup
• if so, merge

[elrido]

So these are the composer development dependencies, I'd guess, pulled in from phpunit:

PrivateBin/composer.json

Lines 36 to 38 in 771d7a3

	"require-dev" : {
	"phpunit/phpunit" : "^9"
	},

The recommended way of running composer to generate optimized autoloader can be seen here in our Makefile:

PrivateBin/Makefile

Lines 11 to 12 in 771d7a3

	composer: ## Update composer dependencies (only production ones, optimize the autoloader)
	composer update --no-dev --optimize-autoloader

I would not want to commit these into the repo (tough I'm glad they didn't also include the suggestions, the cloud SDKs are huge). We could:

• add them, but tweak the autoloader not to deliver them and exclude them from the release via export-ignore .gitattributes (sounds messy)
• explicitly ignore the vendor libs we discovered that way, so they don't get committed by accident (won't work for the autoloader and likely requires updating whenever we update composer deps)
• figure out if there is a way to disable this default behavior (though having phpunit is actually handy, i.e. for updating the SRI hashes)
• figure out if we can have it install the dev deps elsewhere, outside the git repo?

[rugk]

Note we can also configure the GitHub dev-container here: https://github.com/PrivateBin/PrivateBin/new/master?dev_container_template=1&filename=.devcontainer%2Fdevcontainer.json

Maybe we can tell it to run the command as wanted?
though… of course… for development as you do there, you usually likely actually want to have the dev-dependencies in ther ehmm…

[elrido]

Ok, that is something I can investigate over the weekend. How we solved this in our unit testing container and I do on my dev envs is that I install the dev-dependencies (phpunit) via:

composer global require "phpunit/phpunit:^9"

This installs it into ~/.config/composer/vendor/phpunit/phpunit/phpunit. It can then get added to the PATH env var or symlinked into ~/.local/bin/ or /usr/local/bin depending on personal preferences.

Hm, we may just be able to use our unit testing container image, it also has mocha pre-installed for driving the JS tests.

[rugk]

I would bet mocha is preinstalled there too, that mixrooaft image has like lots of stuff preinstalled haha. And apparently some clever init scripts. But yeah feel free to fiddle around…

[elrido]

If we can't turn off those init scripts and phpunit is not preinstalled we will likely have to substitute the image.

[elrido]

FYI: I have not forgotten about this, but not yet figured out how to prevent it from running composer or how that composer run is triggered. I reviewed the default php configuration and it's Dockerfile - the container image simply has a number of tools including git, apache, npm and composer preinstalled, but I didn't spot what commands get executed in it or how that can be controlled.

[rugk]

Indeed strange – could not find anything either… Though, unrelated, but that sounds inter)esting for having www directly serve files (not looked deeply into it).

[rugk]

Whereever it comes form I have setup codespaces similarly for a Python project and it was quite cool: chaos-jetzt/website_pelican#38

You can configure it with a JSON and more JSONs can configure VSCode then. See https://containers.dev/ for the .devcontainer spec.
There we could also run commands, so we can keep the custom image and could then maybe just delete the "bad" files or so? I dunno… We just need to take care not to delete user-changed files or so hehe, because in Codespaces you can e.g. also transfer/keep your git commits when switching from the simple VSCode editor (you get that by default AFAIK when going to github.dev) to codespaces (where there is a real VM or so behind it).

[rugk]

BTW https://devpod.sh/ is another toll for running that locally or with some other cloud providers.

[rugk]

BTW the thing why it did not work is that it uses a generic image/universal one by default. Switched to the PHP one now. After alll we could also use our own but it is based on alpine so much stuff may not be compatible hmm…

Also we'd want tight integration into VSCode there…

Anyway, got it work basically, PrivateBin even starts by default and you can open it. And AFAIK the files are not created anymore, are they? However:

• I did not got xdebug to work, it is already compiled and included by default and such stuff, but in VSCode only single file debugging (by creating a test file and executing it) works.
  Using the built-in webserver and debugging does not work and the webserver also shows a 404/empty page?
• Also mocha fails as the extension searches for nyc hmm? IMHO it is still strange that this does not work˝ I already added an npm install --global for it but it searches only in the local node_modules path arg… To fix this, one may add custom settings into VSCode via customizations.vscode.settings (or can get it to use npx somehow or is there any ENV var we can set?
• Finally also the PHP unit tests (via "PHPUnit Test Explorer") do not work, I can click run in the sidebar, but it just… fails hmm?
• I added some stuff as optional (only workspace suggestions) and apparently these DEVSENSE VSCode extensions are also propritary as there is no source code and some license file hmm? SO maybe we should also just offer these optionally or we say having an out-of-the-box (OOTB) experience (for fast contributing) is more important for us?
• Also minor idea: maybe we should move the dev guide back into the repo., because then we could open it by default when starting the container?

The cool thing is how easy you can debug it. Just create a PHP file with phpinfo etc. hehe…

[elrido]

I've rebased the branch to remove the original commit with all those files and the revert, to prevent these blobs becoming part of the git history.

[elrido]

I'll re-test it as well over the weekend and try looking into your listed points as well. My initial comment to some of these:

• nyc can be used as wrapper around mocha for generating coverage reports, but mocha can also be used on it's own (our testing doc may not make that clear enough - maybe wording can be improved)
• good idea about the dev doc, now that we use the doc folder