Dev container for Vue 3

[fkromer]

This dev container aims at providing an as reproducible as possible development environment for Vue 3 (Vue Next).

[ghost]

All CLA requirements met.

[Chuxel]

//cc: @AarynSmith who owns the Vue dev container

[AarynSmith]

LGTM.

[fkromer]

@Chuxel @AarynSmith The container uses the typescript-node image as base. The its Debian, Node.js and TypeScript versions seem to be hard pinable via VARIANT arg (BASE_IMAGE_VARIANT in vue-3 container). As the base image hard pins the versions "by built time" the versions of Node.js and TypeScript are not really configurable. However I'll change the default value to "0.202.3-16-buster":

• Debian buster
• Node.js 16.3.0
• TypeScript 4.3.5

In the typescript-node base Npm globally installed tools eslint, tslint-to-eslint-config seem to be "hard pinned by built time" but are not really configurable as well.

In the base image yarn seems to be not installed. I'll add it as well.

As soon as I made the changes and you are ok with it I'd like to squash the commits BTW.

[fkromer]

@Chuxel @AarynSmith I've made the missing changes in my lunch break. Exemplary settings are still missing. But from a container image point of view probably ready for merging. What do you think?

[Chuxel]

A few things here. I think this may be getting a bit too specific and divergent from other things in the repository. A few questions/comments:

1. Is there some reason that this could not be a variation of the existing Vue definition? This seems like version updates plus some additions. Couldn't a version argument drive this?
2. If you're expecting something to show up in the "Add Dev Container Configuration Files" UI, then the # [Choice] and # [Option] comments are required in the Dockerfile. Our standard for the image is to use VARIANT (as in image variant) for that argument.
3. yarn 1.x is there installed as a Debian package (not an npm one). Yarn 1.x hasn't changed aside from fixes in a while and is primarily there to bootstrap yarn 2+ which is installed locally, not globally. I suspect including a yarn version in this case will actually create confusion rather than eliminate.
4. The global packages are there as an option if you don't have a package.json. Because of the maintenance overhead, they should default to the latest rather than a specific version. If someone then wants to pin to a particular version, they can make that choice based on their knowledge without needing a redeployment of the definition or VS Code extension.
5. We also don't typically include personal preference extensions like GitLens here - only those that are critical for the scenario. VS Code's settings sync allows you to ensure the things you prefer are synchronized, so only "must have" or really important extensions are included here.
6. Definitions here should not pin to a specific version of an image since this prevents security fixes from getting picked up. Our standard is to use the major version (non-breaking). If someone wants to pin for a specific project, cool - but we don't want to include that by default. Things get out of date fast.

Make sense? Thanks!

[fkromer]

@Chuxel

1. This repo could be merged into https://github.com/microsoft/vscode-dev-containers/tree/main/containers/vue of course. I just sticked to the convention in the repo where major versions are kept in different containers.
2. I did not know and will have a look into this topic.
3. Sounds reasonable... I'll revert the yarn installation commit.
4. Right. Installing packages on a per project basis using npm or yarn is the way to go. yarn2 should be installed per-project. This requires to install Yarn globally which is used to spawn the local ones. You said yarn2 is available via typescript-node base, right? Then everything w.r.t. that topic should be fine.
5. Makes sense. I'll put them back into recommended extensions. As I can remember I had to install them every time I opened a development container. Is there a way to persist recommended extensions after they have been installed?
6. Makes sense. What exactly should I change then?

[fkromer]

@Chuxel @AarynSmith

1. I'd suggest to not merge vue-3 into vue (yet). Some globally installed frameworks are supported in Vue 2 only, not Vue 3 yet. Considering this would result in cluttered and error prone conditional logic (RUN statements, etc.).
2. Done.
3. Done.
4. Should be fine.
5. Done.
6. Should be fine.

Pls let me know if I missed something or if there shall be changed something different in addition.

[kosperera]

@Chuxel @AarynSmith Shouldn't this be a feature instead of its own container, say, vue, and then provide versions and other parameters as part of the feature?

[bamurtaugh]

Thanks for opening and for the discussion so far!

As a heads up, our team has been actively focused on an updated plan for community contributions and this repo moving forward, which we've now outlined in this issue: https://github.com/microsoft/vscode-dev-containers/issues/1589. This includes moving to a couple new repos for images (https://github.com/devcontainers/images) and Features (https://github.com/devcontainers/features).

We anticipate to have a similar repo and distribution process for templates/definitions. We'll keep everyone updated (likely via another issue in this repo or comment on https://github.com/microsoft/vscode-dev-containers/issues/1589) when our new templates repo is available and the process is defined.

I agree with the comment above that it'd be worth exploring if this could be made into a Feature.

Please let me know if you have any questions, thank you!