Yeoman default template as a part of the docker's image about docker-spfx HOT 12 OPEN

The maintenance of this image would be a nightmare and the ROI would not be worth the effort needed to support such an isolated use-case. With the elimination of the local workbench, trying to develop SPFx project while offline is not possible for SPO since the hosted workbench or live SPO site is required. I'm not sure how on-prem dev would work either, unless your SP dev farm is running on a local container/VM on your device.

from docker-spfx.

Definitely OK, I very appreciate your decision.
Thank you very much.

from docker-spfx.

Thanks for reaching out. What do you mean exactly with Yeoman default template? Do you mean, you would like to have the image contain all packages required to scaffold each combination of a SharePoint Framework project (eg. on-prem vs. on-line, web parts vs. extensions, React vs. Knockout vs. no framework) so that you can use it offline?

from docker-spfx.

Thank you for the answer.
I mean that the image should include all packages required to scaffold a few of the most used combinations, like: Default Name --> SP2016 onwards --> Current Folder --> Default WebPart Name and Description --> React/NoFramework.
On my opinion, this is crucial for on-premises and offline (particularly) SPFx development.
Thanks, Alex.

from docker-spfx.

I can totally understand your suggestion. I wouldn't replace the existing image, but will see if we could create a separate one. That way everyone can choose if they want to use the one with precached packages or without. I'll leave this issue open until I know more if this is possible, ok?

Once again, thank you for reaching out 👍

from docker-spfx.

as far as I know, yeoman was a part of the latest docker image versions, or is there still an issue @alexalexpod?

from docker-spfx.

@shurick81 the suggestion was to include all packages required for a scaffolded project in the image. Right now we have Yeoman, the generator and gulp but not the actual SPFx libraries, which was the request. Thinking of it, the question is if we should follow this path, as it would mean that we'd need to regularly refresh the image to fix any issues with any of the hundreds dependencies in the tree.

from docker-spfx.

I see now, and that would probably something we do in a separate image, right?

from docker-spfx.

Correct, that was the idea. The question is though, if it's still relevant and worth the effort to maintain the downstream dependencies. Since we just got this one request almost 4 years ago, my gut feeling says to hold off working on it until we see more demand for it.

from docker-spfx.

But is not it like every project might have different package versions required? For example, two projects might be skaffolded using spfx 1.13.1 but they have a bit different versions of the used packages?

@alexalexpod, is it still demanded for you?

from docker-spfx.

I think the challenge is with the dependencies changing over time. I don't know if SPFx locks on specific versions of its downstream dependencies or not. If it doesn't, then a project you create today, could theoretically use different dependencies than a project you created yesterday.

from docker-spfx.

the way to maintain it will be scaffolding projects and keeping cache files or how does it exactly work with modules?

I wonder how a user will select the image that is needed with specific module versions...

for example, the image versions can be like this, right?

• spfx:1.14.0-react-16.13.1-office-ui-fabric-react-7.174.1

and we could end up with like thousands of different combinations? Otherwise how we predownload these modules to the image? I'm really curious to make some POC in order to verify the viability.

from docker-spfx.