This definitely belongs in a separate repo; I don't use Docker myself and can't commit to maintaining it. Separately, a docker file for developing nvm will rapidly be misused as a docker file for using nvm, and that won't be good for anybody.

hmmm ... we still have problem on running tests locally, I believe that docker can help in this part. As nvm is under a person account not an organization account, I'm not sure how to make it separated, or maybe just be unofficial, but for the local testing works, it'll be definitely good to use docker to isolate the environment with very low overhead and complexity IMO, what do you think?

The reason of this PR 😅 : #1339 (comment)

I'd be happy to review adding one, but I don't use any of those tools myself.

Regardless of docker or no, the tests need to be fixed so they can be run and pass locally regardless of NVM_DIR location.

Also, Mac OS X is one of the most important platforms for nvm, and that can't be tested with docker; which means that id rather perfect the generic dev story before focusing on a container one.

You are correct about that comment, and I appreciate the PR. I will leave it open, but do not plan to merge it in the medium term.

I thought there is a PR trying to add MacOS test in Travis CI already, there should be no conflicts about testing on MacOS and adding Dockerfile, am I right?
I think it's better to have a isolated environment for testing, not only working directory, it won't take the focus or mess up the development work, but will only make it cleaner.

As it's for development environment usage, the docker image will be 1.3GB fat and it needs about 15 mins to be built, not thin and not quick at all, so I don't agree that it will rapidly be misused as a docker file for using nvm, it makes no sense.

Fair points. I don't think these files need to be downloaded by users who install nvm using git, though. Can you think of a way to avoid that?

If you wanna do that, yes, we can use sparseCheckout, and we should checkout only nvm-exec, nvm.sh & bash_completion, other files aren't needed, agree?

I'd prefer an exclusion list approach, rather than an inclusion list approach - git updating needs to grab new file by default, so that i can split things up into separate files in the future.

Can we use sparseCheckout and check out everything except certain folders?

Nope I don't think so.

Then we'll need another solution, I think.

I think we just don't need to be so afraid of misusing, should we? They have no reason to misuse it :)

btw @ljharb, I think we can update sparseCheckout in each versions' install script if you really need that, not a problem at all

Actually I just found that this really really help me debug nvm problems, as it's purely isolated and I can spawn multi containers to test at the same time, which saved me many hours, hope we can give it a try, make the contribution easier for the others.

@ljharb try docker build -t nvm . at the root of nvm, then you'll have a docker image named nvm, if you need it be tagged like tagged commit as version in git, try docker build -t nvm:version .

Use docker images to get the result, it'll looks like:

REPOSITORY         TAG                 IMAGE ID            CREATED             SIZE
nvm                latest              9ca4c57a97d8        7 days ago          1.22 GB

Docker images published here: https://hub.docker.com/r/peterdavehello/nvm/ wtih v0.33.2 tag.

@ljharb is there anything else I can do here? Thanks.

Is there any value in constraining this to a docker subdirectory?

@ljharb do you mean you're considering to put it in a docker folder? I don't think we need to do that as our root is the same the repo root.

Yes, so that docker-related files don't clutter up the main repo root.

I'm not sure if it has some value, as we are not going to build production environment with many different base like nodejs would build with different operating systems which would need to be separated.

Personally, the current status looks good enough to me.