New command to start SPFx container matching the project version

[waldekmastykarz]

What do you think about adding a command like spfx project docker start (or spfx docker start?) that would detect the version of the current SPFx project and run the command to start the corresponding Docker container?

This command would simplify looking up the command to run the container and would automatically include mapping ports, mounting the volume, etc.

[waldekmastykarz]

@pnp/cli-for-microsoft-365-maintainers @hugoabernier @shurick81 @DonKirkham any opinions?

[DonKirkham]

I like the idea, but have questions:

• So this primarily would be for projects that do not have .devcontainer files?
• If a .devcontainer is present, would it use that?
• If this is run from the command line, what is the final result? Do you end up with a remote session from the command prompt? Can you open VS Code from that prompt?
• A similar command to add the .devcontainer files would also be nice.

I'm trying to clarify what the use-case for this would be. If user just created the project, then they already have the needed files to run it. (This would be the place where the ability to add the default .devcontainer files would be helpful.) If they are using PnP samples, those already have (or will shortly) .devcontainer files. That just leaves grabbing a non-PnP sample from somewhere or opening a previous project that doesn't have .devcontainer files.

If this could be done completely from the command line, with no need to go through VS Code and the Remote-Container extension, that would allow user to download a sample, run the command, generate the package, and deploy that package without ever engaging VS Code. I have heard user request the ability to just install a sample from PnP without having to understand "all the dev stuff." This would help them (although I think we all agree that it is a bad idea to install any custom code without understanding it.)

[waldekmastykarz]

So this primarily would be for projects that do not have .devcontainer files?

Yes. It's meant as an easy way for folks to run SPFx projects.

If a .devcontainer is present, would it use that?

We'd need to think about that. If there is a devcontainer, it's an image definition, that might need to be built first. It might be also exposing additional ports and volumes that we don't know about in the CLI and might not pick up.

If this is run from the command line, what is the final result? Do you end up with a remote session from the command prompt? Can you open VS Code from that prompt?

The final result is a Docker container running on your image, same as if you'd run the docker run command manually. It doesn't open a remote session, it's just a shortcut so that you don't need to memorize the whole command.

If user just created the project, then they already have the needed files to run it.

At this moment they don't. If you create a new SPFx project using the standard generator, there's no devcontainer definition.

I have heard user request the ability to just install a sample from PnP without having to understand "all the dev stuff."

That's a different scenario, because it would require that we run the container somewhere without you having to install anything. Codespaces could be an option, but it would still require you to build the package. We could provide a script for it and perhaps automate it, but that's a whole different scenario.

[DonKirkham]

The final result is a Docker container running on your image, same as if you'd run the docker run command manually. It doesn't open a remote session, it's just a shortcut so that you don't need to memorize the whole command.

I am still unclear on what the result of this command would be. If the container is just running and I am not connected to the container, how do I interact with it? If I understand, the -it command opens a prompt inside the container after it is started. To me, that feels like a remote session, but I could be completely wrong in my use of that term.

[waldekmastykarz]

I am still unclear on what the result of this command would be. If the container is just running and I am not connected to the container, how do I interact with it? If I understand, the -it command opens a prompt inside the container after it is started. To me, that feels like a remote session, but I could be completely wrong in my use of that term.

So running spfx docker run would run docker run with the right arguments for you. The net result is the same as calling docker run yourself.

[hugoabernier]

I like the idea! My two cents' worth:

• Whatever the command is called, I would suggest that we make it consistent with spfx project devcontainer add #3098
• Because we use spfx-startup.sh as the standard approach for launching remote containers with samples, I would recommend that creating a new container would result in the same generated artifacts as spfx project devcontainer add #3098
• I have taken the liberty of writing the decision flow I believe would be ideal:

graph TD
    A[CLI docker start] --> B(Look for existing container)
    B --> C{Existing container?}
    C -->|Yes| D[Launch container]
    C -->|No| E[Run CLI new container #3098 ]
    E --> |Container created|D

Loading

[hugoabernier]

there will be a devcontainer folder at the root

[waldekmastykarz]

Right but devcontainer describes an image, not a container. So rather than just starting a container, we'd need to first build an image and then start the container off of it.

[DonKirkham]

Maybe I am not understanding, but I thought devcontainer.json describes a container based off of an image. It includes settings, ports, mounts, remote user, etc.

@waldekmastykarz isn't the file that describes an image the DOCKERFILE.

The VS Code extension, as well as CodeSpaces use this file when present to build the container. The idea here is to use the file without needing the extension, but I agree that might be the original intent of the new command. Maybe a future enhancement?

[DonKirkham]

Just realized how this overlaps with the #3098 discussion. I still think both are valid and should probably be kept separate. the devcontainer command add the files to the project. the docker run command should have the option to use those files, if present.

[waldekmastykarz]

I took a bit of a shortcut: devcontainer either points to an image that's in Dockerfile or to an existing image in which it's nothing more than run instructions. But if it points to a Dockerfile, then that image needs to be built first.

[DonKirkham]

After watching the demo today in the Community call by @shurick81, it would be nice to have the option to include a repo url in the command, eliminating the need to clone the repo locally. Of course, if you are working with a local repo, using the current folder could be the default if no repo url is included.

[waldekmastykarz]

So basically something like spfx docker run --gitHubRepo https://....?

[DonKirkham]

Yes, although I wonder if we need to limit it to github. the "git clone" command allows and repo url to be used, I think. I know it works for GitHub and Azure DevOps.

[waldekmastykarz]

Fair enough, assuming you're authenticated with the right system, it could be any repo indeed.

[shurick81]

Will it also work if we use CLI in Docker?

docker run --rm -it m365pnp/cli-microsoft365:latest

[waldekmastykarz]

I don't think so because then you'd be trying to start a container from inside of another container

[shurick81]

I totally get the value of such a use case. However, I'm struggling to find reasons why this feature should belongs to "CLI for M365"... Would not it be great instead to have a feature in spfx like
gulp spfx-version that returns the version of the SPFx in the current solution? Then we we could use this call in normal docker run.

[waldekmastykarz]

The thing is that the docker run command isn't trivial and not something you'd type off the top of your head. I can imagine that some folks create an alias which is why I'm wondering if we couldn't simplify it.

[DonKirkham]

In your demo Aleksandr, you use the following commands to run docker for the current project:
sudo chown -R 1001:1001 .
docker run --rm -it -v $(pwd):/usr/app/spfx -p 4321:4321 -p 35729:35729 m365pnp/spfx:1.14.0

I am not familiar (yet) with the first command, but this new CLI-m365 command would automate those command.

[DonKirkham]

While a gulp version of this might be a fine goal, we do not have any control over the OOTB gulp commands. This is a strength of the CLI and if it is valuable, I suspect MSFT will consider adding it to the core project.

[shurick81]

One more question, in case if we do this feature, should it determine the docker image based on the package.json or should it also look at .devcontainer? The latter could help in case a developer is not using using IDE that is not aware of .devcontainer, right?

I think we could try understand the biggest problem that developers now have.

Is that a problem that spfx developers do not know how to start using docker?

[waldekmastykarz]

The original idea was to simplify starting an SPFx container suitable for the current project. Using dev containers is a separate scenario that perhaps isn't an issue because it's supported by the IDE like VSCode.

[shurick81]

yes, ok, let's prioritize this particular concern then while discussing this feature.

[shurick81]

Should we try formulate a user story.
As an SPFx developer, I want to be able to run some short command like m365 spfx docker start so that I don't have to learn nor to document in the project documentation the syntax of the full command like docker run --rm -it -v $(pwd):/usr/app/spfx -p 4321:4321 -p 35729:35729 m365pnp/spfx:1.14.0.

[DonKirkham]

I feel like most of the .devcontainer.json file is just stating the parameters for the docker run command, plus some VS Code specific stuff. That said, I notice that there is no option once in the container to run VS Code, so it looks like the extension does more behind the scenes stuff that originally thought.

[DonKirkham]

Is that a problem that spfx developers do not know how to start using docker?

I would say that most developers have very little experience using Docker. I know I have struggled to learn the vast ecosystem of containers, including Docker and though I feel very inadequate in my knowledge of the subject, I am way ahead of most developers that I talk to. One of the primary barriers is the complexity of setting up containers. This would automate a lot of that complexity.

[shurick81]

I wonder if there are similar patterns for other domains, that are not SPFx related, what is the common practice in the community of Docker users regarding simplifying running docker containers? I's just one line command after all :)

[shurick81]

this feature will have to be agnostic to the platform, because depending on running it in Linux, Windows or Mac it should invoke docker run in a bit different way, right?

[shurick81]

Should this feature also fix these known issues? https://github.com/pnp/docker-spfx#known-issues

[shurick81]

Should this feature also fix Linux file system permissions issues that we sometimes have pnp/docker-spfx#37. The problem is that when we work from linux, we want to git clone using a host system user but the docker image is running with 1001 user and node processes might be running with user id 1000, etc.

[waldekmastykarz]

Is this is a one-off thing or something you need to do each time you run the container?

[shurick81]

only each time you clone it. You don't need to repeat it every time we start a new container, no.

[shurick81]

Do I understand it correctly that the alternative that SPFx developers have currently, without this new feature, is that someone from their team prepares a guidance for each project, how to run it in Docker, right? Something like this? https://github.com/shurick81/spfx-demo-01

[waldekmastykarz]

In a way. The alternative right now is:

• go to the Docker Hub
• lookup the SPFx image
• copy the command to run the container
• in the terminal past the docker run command
• adjust the SPFx version number
• run the command

Using CLI, we could bring this down to:

• run m365 spfx docker run

[waldekmastykarz]

I wonder how easy it is to start working with Docker on Mac, any users here?

I'm on a mac

let me try to play the role of "that guy": it will be easy to run docker run using this feature, but still someone will need to install docker on the developer's laptop.

Correct, we won't be installing prerequisites and we'd draw the line at starting the container

Should this feature also fix these known issues? https://github.com/pnp/docker-spfx#known-issues

Potentially, although it's tricky to automatically change something in the code in a reliable way

[shurick81]

Well I don't think it will be too useful if we don't fix all these problems, but maybe we should start with something. In a long term this looks quite promising, but it will require quite a lot of coding for handling different conditions. Let me put my humble opinion in other words: the way how to call docker run might be just 10% of all the knowledge that one should have in order to start working with SPFx containers. But I think if we fix even these 10% it can be useful, and later on we can aim to fix the rest 90% :)

[waldekmastykarz]

If the simple solution is not meaningful enough and the meaningful solution is too tricky/complex then it's also fine for us to decide not to do it 🙂

Perhaps we should rephrase the question: what would be minimal viable product that meaningfully improves developer experience when using Docker with SPFx?

[shurick81]

If Docker is not installed, it should just output the info about this, right?

[waldekmastykarz]

Correct, we wouldn't be installing docker