Automated documentation update (#257)

Automated documentation update [skip ci]

Co-authored-by: github-actions <github-actions@github.com>

src/docker-from-docker/README.md

@@ -21,17 +21,15 @@
 | moby | Install OSS Moby build instead of Docker CE | boolean | true |
 | dockerDashComposeVersion | Compose version to use for docker-compose (v1 or v2) | string | v1 |
 
+## Limitations
+
+* As the name implies, the Feature is expected to work when the host is running Docker (or the OSS Moby container engine it is built on). It may be possible to get running in other container engines, but it has not been tested with them.
+* The host and the container must be running on the same chip architecture. You will not be able to use it with an emulated x86 image with Docker Desktop on an Apple Silicon Mac, for example.
+* This approach does not currently enable bind mounting the workspace folder by default, and cannot support folders outside of the workspace folder. Consider whether the [Docker-in-Docker Feature](../docker-in-docker) would better meet your needs given it does not have this limitation.
+
 ## Supporting bind mounts from the workspace folder
 
-A common question that comes up is how you can use `bind` mounts from the Docker CLI from within the a dev container using this Feature (e.g. via `-v`). The trick is that, since you're actually using the Docker engine sitting outside of the container, the filesystem paths will be different than those in the container. You need to use the **host**'s paths instead.
-
-> **Note:** The docker-from-docker approach does not currently enable bind mounting locations outside of the workspace folder.
-
-### GitHub Codespaces
-
-In GitHub Codespaces, the workspace folder should work with bind mounts by default, so no further action is required.
-
-### Remote - Containers
+A common question that comes up is how you can use `bind` mounts from the Docker CLI from within the a dev container using this Feature (e.g. via `-v`). If you cannot use the [Docker-in-Docker Feature](../docker-in-docker), the only way to work around this is to use the **host**'s folder paths instead of the container's paths.
 
 A simple way to do this is to put `${localWorkspaceFolder}` in an environment variable that you then use when doing bind mounts inside the container.
 
@@ -47,7 +45,7 @@ Then reference the env var when running Docker commands from the terminal inside
 docker run -it --rm -v ${LOCAL_WORKSPACE_FOLDER}:/workspace debian bash
 ```
 
-> **Note:** There is no `${localWorkspaceFolder}` when using the **Clone Repository in Container Volume** command ([info](https://github.com/microsoft/vscode-remote-release/issues/6160#issuecomment-1014701007)).
+> **Note:** There is no `${localWorkspaceFolder}` when using the **Clone Repository in Container Volume** command in the VS Code Dev Containers extension ([info](https://github.com/microsoft/vscode-remote-release/issues/6160#issuecomment-1014701007)).
 
 ---
 

src/docker-in-docker/README.md

@@ -23,6 +23,12 @@ Create child containers *inside* a container, independent from the host's docker
 | azureDnsAutoDetection | Allow automatically setting the dockerd DNS server when the installation script detects it is running in Azure | boolean | true |
 | dockerDefaultAddressPool | Define default address pools for Docker networks. e.g. base=192.168.0.0/16,size=24 | string | - |
 
+## Limitations
+
+This docker-in-docker Dev Container Feature is roughly based on the [official docker-in-docker wrapper script](https://github.com/moby/moby/blob/master/hack/dind) that is part of the [Moby project](https://mobyproject.org/). With this in mind:
+* As the name implies, the Feature is expected to work when the host is running Docker (or the OSS Moby container engine it is built on). It may be possible to get running in other container engines, but it has not been tested with them.
+* The host and the container must be running on the same chip architecture. You will not be able to use it with an emulated x86 image with Docker Desktop on an Apple Silicon Mac, for example.
+
 
 
 ---

src/node/README.md

@@ -22,6 +22,24 @@ Installs Node.js, nvm, yarn, and needed dependencies.
 | nvmInstallPath | The path where NVM will be installed. | string | /usr/local/share/nvm |
 | nvmVersion | Version of NVM to install. | string | 0.39.2 |
 
+## Using nvm from postCreateCommand or another lifecycle command
+
+Certain operations like `postCreateCommand` run non-interactive, non-login shells. Unfortunately, `nvm` is really particular that it needs to be "sourced" before it is used, which can only happen automatically with interactive and/or login shells. Fortunately, this is easy to work around:
+
+Just can source the `nvm` startup script before using it:
+
+```json
+"postCreateCommand": ". ${NVM_DIR}/nvm.sh && nvm install --lts"
+```
+
+Note that typically the default shell in these cases is `sh` not `bash`, so use `. ${NVM_DIR}/nvm.sh` instead of `source ${NVM_DIR}/nvm.sh`.
+
+Alternatively, you can start up an interactive shell which will in turn source `nvm`:
+
+```json
+"postCreateCommand": "bash -i -c 'nvm install --lts'"
+```
+
 
 
 ---