What if we bring back the SPFx Local Workbench?

[Saurabh7019]

Hey folks,

We have been discussing this internally and wanted to open it up here. Curious to hear what you all think.

The SPFx Local Workbench was deprecated in version 1.13.1. Since then, running it requires a tenant. That wasn't a big issue, but things have changed. There are now a few new challenges that make the case for bringing it back.

A few reasons why we think it makes sense:

• The SPFx developer program has been inactive for some time now. Although it has not been confirmed in what shape and when it will come back, there is a possibility that it could come back as a paid option, it may come back as a paid option. That's a blocker for anyone who just wants to build and test a few web parts without setting up a full paid tenant.
• One of the pain points in the past was mocking SharePoint data manually and adding env.local checks in the code. That's still needed, but with Dev Proxy, mocking responses is way easier.
• One benefit that didn't get much attention before, local workbench makes integration and behavior testing possible. You can serve the solution, click around and test the real web part and this is all possible without auth. Dev Proxy can handle the mocked API responses.
• The M365 Agents Toolkit uses a local workbench approach too. Not fully styled like Teams, but gives opportunities to test agents locally. Same idea could work for SPFx.
• Super useful at trainings and workshops where we run SPFx tutorials. Attendees could build and test their solutions without needing tenant access.

We are thinking about a small npm package that serves a static HTML page with basic JS and CSS to simulate a SharePoint workbench. It wouldn't be a full replica, just enough to load SPFx web parts locally and make testing easier.

Thoughts?

[martinlingstuyl]

Hi guys,

As to the benefit of testability: how would this be a benefit as opposed to the remote workbench? The same would be possible there I think? The same flies for dev proxy.

Now I must say I still have my developer tenant, but I know and fully understand the pain point there.

As to me personally: in all the years that I built SPFx webparts and extensions I think I never actually used the local workbench...
I'm not against bringing it back of course, but I don't think I (personally) would really need it back as well. I doubt I'd use it. But I'm just one guy of course, and this is really just a personal view built on how we use SPFx 😬

We often build stuff remotely, while deploying the SharePoint artifacts that we need using (for example) pnp templating or scripts. So our "mock data" is actual SharePoint artifacts and content. We just build it out on SharePoint from the get go. The power of that is that these "mock" SharePoint sites and artifacts are easily deleted and reprovisioned in the shape that we need them to be. Another benefit of that is that we are actually prepping for live deployments while building our "mocks" in actual SharePoint. Of course this method has drawbacks of its own, but it works for us, and our SPFx projects are usually quite small.

[Adam-it]

Good feed 👍. Thank you for your answer 👏👏👏

[mkm17]

Hi everyone,

I haven’t used the local workbench at all. From my perspective as a SharePoint developer, you’ll need a real SharePoint environment at some point.

I'm not sure how much effort it would take to fully recreate the local workbench, but it's likely that it would also require constant updates whenever Microsoft changes the behavior of SharePoint pages.

---

While writing this post, I started to think that maybe recreating the local workbench isn't really necessary. However, if we can enhance the solution compared to the existing remote workbench (for example, by showing the web part in all types of sections to immediately check mobile behavior) then it could be a useful tool for a wider audience.

[Adam-it]

Good feed 👍. Thank you for your answer 👏👏👏

[Saurabh7019]

Thanks Martin, that's how we do it as well. I also switched to the SPO workbench right away and never really used the local one. And I agree, the local workbench doesn't offer any real testability advantage over the remote one.

The only real benefit would be when tenant access is a blocker. For example, in trainings, quick demos, or when testing basic logic without needing to set anything up. Like when you are running an SPFx workshop for a lot of people and not everyone has a tenant. This could help them get started quickly.

Michael, the effort shouldn't be much since we were not thinking of fully recreating workbench or matching all features. Just a lightweight HTML and JS page that can load SPFx web parts locally. Nothing more. If we start enhancing it to support mobile responsiveness and test different section layouts, we may be opening up a bigger scope.

We were discussing this internally as a possible tool in SPFx Toolkit and were divided on if it's worth the effort. So far, it looks like it is probably not needed.

[andrewconnell]

@mkm17 said:

From my perspective as a SharePoint developer, you’ll need a real SharePoint environment at some point.

+1 to this

The local workbench has been gone for a long time now & it was limited before supporting only a subset of web part & ACE projects. It's not a real-world scenario and was less useful than a similar existing project for Teams (M365 Agents Playground, formerly the Test Tool).

IMHO, if a new local workbench option spun up, unless it addressed almost ALL the old limitations of the old one (such as those below), I wouldn't use it nor recommend or even mention it to my students.

Legacy local workbench limitations:

• doesn't work with permissions
• doesn't support any type of extensions
• doesn't support web parts as SPA's
• doesn't support real world data access for the SPO REST endpoint

[Adam-it]

This is a very good comment. TBH when we were brainstorming we did not consider any of the points you mentioned 👍
Thanks for your answer 👏

[StfBauer]

• Does not support any of the real-world web part zones
• Was unable to store the web part configuration from one development session to another, for example, in local storage and webpart-id+instance

I wouldn't even mind if the hosted workbench were to go away, since it has the same limitations as the local hosted workbench. Okay, a bit less, but overall, it does not serve any development needs.

The proven good way to develop web parts is to work with

• A local app catalog in a site collection
• Deploy a development build
  • gulp bundle and gulp package-solution without-- ship
  • Upload the sppgk file
• Add a web part to a dedicated page

Additionally, I create a secondary dedicated testing page, where I add all section variants that include one or multiple web part instances per section. This way, I get a direct overview of all the configuration options. I can test the responsive behavior on a dedicated page.

Again, I never use the hosted workbench and would not mind if it were to disappear as well.

[juliemturner]

Everything that @StfBauer just said. Even without a dev tenant if the user is building solutions with SPFx there must be intent for it to go somewhere. If that's their job, then creating a site collection with a site collection app catalog is the best way to do this type of development. Create and deploy a dev build to that site collection and party on with all the functionality you could need because it is SharePoint. The only scenario in the original thread that I could somewhat understand is a training/workshop scenario but I'm not sure the work required to build a useful workbench is worth that one scenario.

IMHO there is just no need for a workbench.

[Adam-it]

Thanks @StfBauer, @juliemturner for the valuable feedback 👍👍👍👍
recreating the workbench even in a basic initial state would be some amount of work that is why it is extra important for us we don't waste this time and better invest it in other areas 🙂

[Saurabh7019]

Thanks everyone for sharing your thoughts.

It is clear from the discussion that the basic lightweight local workbench we were thinking of wouldn't really help with SPFx development. For training or workshops, it might have helped a little, but that doesn't seem like a strong enough reason to build and maintain a new tool.

We will stop investing in this idea for now and focus on other things. Thank you again for you feedback, we have got enough input to write a clear spec in case we ever decide to revisit it in the future.