Sp-dev-docs: Feature Request: Simple and Advanced Generator

[mike-morr]

I think it needs to be a priority to add an option to the yeoman generator to get a straight forward build system out of yeoman.

This project's build system is amazing. Dead simple and very fast. It's near perfect as long as you want to use the exact technology decisions the project has made. We say people can use whatever they want, but the current build system makes it counter-intuitive to actually use anything besides what has been prescribed by default.

I tried to add Mobx for example only to get an error that some old version of Mobservable is already installed and needs to be removed. How do I do that without breaking whatever you have that relies on it? Almost everything I try to customize ends up this way.

Developers shouldn't be waiting on instructions for how to integrate Angular 2. These developers should be empowered to give the community instructions on different ways to integrate Angular 2 by having advanced mode where the build system is straight forward. Trying to build a boilerplate with the stack the developer prefers based on using this generator is a non-starter right now.

IMO, your choice of technology to build SPFx, should never interfere with what I want to use to build on top of SPFx. Trying to write "special instructions" on how to get X to play nice is not going to scale. This ecosystem is way too broad.

With this in mind. I think there should be a simple and advanced mode. Simple mode is already nailed with near perfection in my opinion.

Here is what I would love to see.

Simple Mode

• No big changes to what is out there now
• No big hooks into the build system
• No added complexity
• Minor customization points that are config driven

This generator is near perfect for demos, documentation, training sessions, MCS engagements where the customer (or the MCS consultants) don't have mature JS experience. Also, for most small, simple webparts where the developer just wants to build something quick and where they are fine with the stack as prescribed. I see this covering 40% - 60% of scenarios. This is almost as beginner friendly as it can be like it is now.

The build speed is seriously amazing. I have been playing with a lot of open source yeoman generators and starter kits for the past few years. I am pretty sure this is the fastest one I have come across.

Advanced Mode

• Expose the entire build system along with the source code.
• Put it in an advanced section of the generator menu, another generator altogether or just release it as a boilerplate.
• If we can keep the lightning speed of the current generated template, that would be awesome, but not required.

Aurelia Skeleton Navigation - Please take a look at these skeletons. That is what I think advanced mode should look like. Particularly the skeleton-typescript. This is a super prescriptive boilerplate, but anything can be swapped out with minimal effort. The build system in all 6 of their skeletons expose the power of gulp and webpack.

With the current state of the project, you basically have no choice for the developer stack. We can't hide all of the functionality of gulp and webpack and call it embracing open source. While the generator is perfect for a lot of scenarios especially the devs coming from C#. The developers that want to use the testing tools, libraries, specific versions of libraries, and workflows they already know are pretty much road blocked. IMO, open source implies making it open, easy to fork and extend, etc.

General Feedback

I think landing non-Microsoft developers is going to be difficult after they see the build system. It looks completely different than 99 out of 100 other projects using gulp and webpack on GitHub. When I say different, I mean unless they want to dig through the node_modules folder, they won't even be able to find the build system. These folks are not big fans of hidden complexity or being told what to use. They are all about either "How can I plug your stuff into my stuff?" or vice versa. I also believe this will apply to a lot of the C# developers after they get more experienced.

I know it is very early days, so please don't take this as criticism of the current state. I am just trying to explain why I feel strongly that this is a much needed feature. This is seriously great stuff and is only going to get better.

[vvolodin]

Very nicely written, I hope people behind the project will listen to constructive feedback like this.

[patmill]

Thanks @mike-morrison and @vvolodin . I think your request is totally reasonable. To be honest, we've spent most of our time refining the design / architecture / API / etc. of the runtime portion, and less time on the build tool chain. We effectively released the build pipeline that we developed for our own projects. It's (un?)fortunate that a lot of the feedback and issues is around the tooling and build chain. Either that means that the actual architecture of the CSWPs is relatively sound and logical, or people haven't gotten past the tooling to find fundamental issues with the feature. I'm hoping it's the former.

Anyhow, brainstorming a bit on how to proceed here. I think what is desired is a minimal generator that lays down a small package.json that would allow you to npm install the required bits, build, and allow it to run in the SharePoint hosted workbench. Maybe a starting ts file. It would need to create the manifest file and the other bits and pieces that are required by the runtime. You would need to use our bundle / packing logic, since the sp-module-loader that is executing at runtime is dependent on it, and we don't really want to support and debug multiple different loaders. One good starting point would be, as @sympmarc mentioned, to document the existing package.json and what it has / why it has it. I'll be honest though - I don't know offhand how easy it will be to build without using the gulp-core-build pipeline. We'll need to dig in.

Presumably there would be a desire to have the local workbench and such be added to the project as an option. You would likely not have the various extensions we have made to the build system to handle localization and so on, but I think that's the general idea.

Now as for actual execution on this, I wouldn't mind trying out something a bit different for us, which would be starting the whole thing in the open on github, and have it be a community driven affair. Would that be of interest to people? I can't help but think that us doing it on our own will result in a bad game of telephone where we interpret your thoughts incorrectly.

[mike-morr]

Thank you @vvolodin . Unfortunately, listening is the easy part. The team doesn't have infinite resources and they are tasked with bringing a million developers over from an existing stack that frankly is much more comfortable compared to this world. Think of C#/Visual Studio as a fancy Recreational Vehicle (RV) with all the bells and whistles. (Java|Type)Script and vscode is like heading out to the woods with nothing but a sleeping bag and a backpack. They are both fun until you need to use the restroom or cook something. :)

In addition, the team is trying to target a new diverse group of developers who have been doing this for years and each have their own idea of what should go in a backpack and how fluffy the sleeping bag should be. They also need the output to be in a specific format so it can be plugged in and managed by diverse enterprise organizations in diverse verticals. On top of all of this, I'm sure a lot of this is new to the team as well. Have we talked about training and documentation yet?

Make no mistake, this team is walking a tightrope.

[mike-morr]

I love everything you just said except about the workbench. I think the workbench should be required in both modes. I will address that in the other issue regarding size of the dev stack though. So I think a bare minimum boilerplate would be enough for the community to take it from there. From what I can tell the gulp-core-build stuff looks valuable, so I am not sure I would strip it out. Instead make it accessible. I am going to mock something up so it is easier to talk about. @patmill

[patmill]

We're closing down old entries here that aren't explicitly issues. If you are still interested in this, I would recommend opening up an entry in user voice ( https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/ ), as that is where we want to track feature requests.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues