 OK. Hello everybody. Thank you very much for coming to my session. This is about why module builders should be in your developer toolkits. So, a little bit about me. My name is Joachim. I am Joachim on the Drupal community master on instance. I am Joachim on Drupal.org and you can also email me. I have a bit about me. I'm a dad. I'm a cargo bike rider. I'm a jazz pianist and I'm a back-end dev at factorial. You can check out open positions where really cool. So, module builder is a code generator. The first question is what's the purpose of code generators anyway? I think the first reason is to generate all the boilerplate code that is tedious to write and every... I'm going to say Drupal has a lot of that but everything has a lot of boilerplate. The second is documentation because it saves you time looking things up. And the third is just plain old laziness. I am one of the laziest developers. I know I will spend weeks going down a rabbit hole to write a condiment parser because it annoys me to have to keep passing the mustard. XKCD reference. I was going to see if I can put the cartoon in that but I didn't bother looking up about copyright. But why specifically module builder? There are other code generators available. The first one is it has a nice shiny UI which we'll see in a moment. The second one is reusability of your generated module which I'll come to that as well. And the third is that it is analytical. So, boilerplate. Is that big enough? Can everyone see that? I don't know how to be big in it anyway. Some examples of boilerplate code. We have entity type annotations. We have root declarations. And we have dependency injection. Now, I have to say dependency injection. That boilerplate is going to get reduced fairly soon because people like long wave are making big efforts to have fancy symphony auto wiring in boilerplate. Sorry, in dependency injection. But there's still going to be some boilerplate. It's unavoidable. Documentation. It gives you time finding the things you want. This is part of the module builder UI. You want to create a plugin or a form or a controller class. You want to inject some services. There's a nice autocomplete. You can just think, I need the thingy fluff and fluff and manager. It's the entity type manager. It autocompletes it for you. You don't need to keep remembering the exact names of services. We're going to find them. And the laziness. You want to keep remembering all the different possibilities because they are there in the UI available for you. This is the controller. A piece of the controller generation form. You get to choose whether your controller for your root is a controller class, an entity form, display an entity list, and so on and so forth. And then likewise the access type. You can get custom access, entity access. No access of control at all to live dangerously. And so on and so forth. Module builder stores the... This is where it's going. I'm going to say the word module over and over again. Module builder saves a module as a config entity. And so you can come back to it. And you can create it, add some plugins or whatever. And then a week later you'll actually know my custom module. I also want to implement such and such a hook. Such and such a plugin. You can return to it, add things to it, generate the code again. Nothing's hard coded in module builder. Unlike other code generators which are also available. Out of the box it knows nothing about hooks, about plugin types, about services. It instead analyzes your code base. Now the reason that's really important is that it will learn about plugin types and services in your contrib modules, which are in your code base. And also the ones that are invented by any custom code you have. So the first step you need to do when you install module builder is go to this analyze site code, which you click that big button there. And it will run a batch and just look at your code. There's unspeakable things it does under the hood because there are some codrib modules out there that don't implement their plugin interfaces properly. And nobody realises because if you don't instantiate the plugin nothing happens. I've had to do some terrible, terrible things to make sure that it's safe to actually instantiate classes that might crash. Look in the code base if you're curious. Once you run the analysis you have this huge list of things that it now knows about. You have hooks, plugin types, services, service tag types, test creation traits, which I'll show later on if I have time, entity types and so on and so forth. And all these things let you select the hooks you want to implement, let you select what plugins you want to create. So for example if you want to create a new plugin you can create a core plugin, a core block plugin. You can create a flag type plugin and so on and so forth because that's been analysed from the code in flag module. What about custom code? Well, I'm doing the steps here rather than live because it's a little bit quicker. So I created a new custom module called Drupalcon Leal and then I went to create a new plugin type. So my new plugin type I get to choose that it's an annotation plugin. The other option is the YAML plugin type, plugin discovery type and then you give it your plugin type ID. These get prefilled magically and then you go to generate code. So straight away a plugin type is a huge amount of boilerplate. You need your API PHP file for the info alter hook. You need your plugin type YAML file which you don't need it in core but you need it if you're using plugin module. You need a service for the plugin manager. So that's two files already, services YAML, manager file. You want annotation field plugin. You want a base class. You want to interface. That's a ton of boilerplate which module builder straight up generates for you. Then if we enable that module and go back to code analysis and run the code analysis again, it picks it up. So it now knows how to create Drupalcon Leal 2023 cat feeder plugins which we just invented five minutes ago. So if you then go to the plugin form, it's there as a selectable plugin type. So I'm worried on the last slide because I was going to... What's the time? I've raced through in record time. Okay, so that's just a short example of what it covers. It can also generate content entities, config entities, forms, roots, things like dynamic root providers, PHP unit tests and a relatively new feature is core has various entity creation traits which it knows how to pick and add into your test class, services, permissions, drush commands, file issues if you'd like to see more things. There we go. Creation traits. These are useful helpers you can use in your PHP unit classes, things like creating image fields, creating media types and so on and so forth. So you just select those when you generate your test class and it adds them in for you. And again, it's discoverability. It's things that you may not have known these existed. Same with PHP test classes. We've got various bases that you can have browser tests, kernel tests, unit tests, so on and so forth. And then you can add in services that you mock and things like that. This is Alvaro's slide with the paella. He did this session for me at Drupal Dev Days because I couldn't make it. So yeah, I recommend you install the module, see what it can do, check out a blog post of mine about how it works, what the idea is behind it. And I'm now going to move over to a little bit of live demo because this is a new feature I've added just last week. So it's seed of the pound stuff. It's now released. Hopefully it's not going to crash. Something I often find I tend to do in module builder is I will create a form or a service or something like that that has dependency injection and I will inject the two services I think I need and then half an hour later I'll be like, oh no, I actually need completely different services and I've written loads of my code already and now I want to generate it all over again and add in these additional services. Now, module builder, when you write code, this is why Alfaro was telling me don't do live stuff, it already knows, it doesn't know how to merge every kind of file yet, but it knows how to merge some types of file with the file that's on disk. So for example, if you add a new service to your module, it will merge the services YAML file with what's on disk, it will merge the new service with that. It will merge the service with what's managed by Git and what isn't managed by Git so you don't accidentally clobber code that you haven't committed yet. That is just for showing what's about to be generated and the checkboxes on the left are selecting which files you're going to write. So there's already this merging facility but I've added something new where you get to adopt an existing module from your code base and bring it into module builder and config entity. Does anyone want to suggest which module we're going to try to adopt? Should we live dangerously and go for book or should we go for node? I think nodes may be a safer bet. This is a really long list because it's got all the test modules. Let's try adopting node. It shouldn't give me a nasty error message like that. That's because I've already made it and I should have deleted it. Let's try adopting flag. We now have flag as a module builder module and now we can adopt individual components to tweak them. For example we might adopt the let's try that's the flag service and we will now under the miscellaneous tab flag service and the services it currently injects and so we can now add our extra services to that if we all remove some and whatever and regenerate the class. That's the end of the demo. Does anyone have any questions? There's a couple of questions. Cool. Philip H is asking if there are risks that tools like this will lead us to a situation where we don't understand the code we're writing or working with anymore. I don't know. I've been using module builder for all this sort of stuff for a very long time ever since Webchick handed the module over to me at Drupalcon Seged in 2008 and I still understand dependency injection. It just saves time. I still see the code but it saves you time and tedium I would say. There's another question from Peter which is is it possible to integrate module builder with version control softwares? Can you say a bit more about that? I mean what do you I'm not sure what I mean it if you mean the I'll show you a better example if I edit something that actually is under version control so I make module builder with module builder these days. There we go. I haven't got much in the module builder yet module builder module but I wanted to tweak a form earlier today and so it knows that these are both under version control and so that I'm not at risk of these are currently unmodified according to Git and so I am trying to it knows I'm trying to overwrite this one but it's also telling me that it's safe in Git. Is that what was meant to yes? Cool. Yep. I think this I can't remember I've got the vague recollection there's something extra I'd like that version control thing to do or the merge status one and I can't remember what it is but it does that. Anything else? There's one last question on here from Lucas. Can I use it in production? No. Do not use it in production it writes code files. See that warning there? Yes it may if you are writing if you're generating an enabled module warning there you might make things crash. Don't. There's a comment from Karen says for me as a site builder I feel this will ensure I make things that are compliant with the expected standards. Do you mean coding standards? So if you wanted to do something like build a custom entity type we'll build you a custom entity type so the module builder is actually the module builder module is the UI part and the code generation part is a separate library called Drupal code builder and the two just work in tandem and Drupal code builder has got extensive PHP unit tests because I'm forever adding features and refactoring and there's so many different combinations with lots of things especially when it comes to entity types that I don't need the stress of what am I breaking when I make this change and one of the things that the unit tests does is it runs all generated code through coder so it checks that all generated code is valid PHP and conforms to proper Drupal code conventions and documentation conventions and so on and so forth. Yep. It saved my bacon on quite a few occasions when I make some change and there's a spare empty line somewhere and boom it catches it and I have to fix it. There's two more questions I think I've just got time for is have you considered adding AI for example to also generate the actual implementation not just the boilerplate? That's not something I'm looking into at the moment because I'm not especially interested in you know fantastic parrots and clever autocomplete. One last question from John which is I admit I don't understand what half the code I'm writing does what's the best way to learn the nitty gritty of DI and what the boilerplate actually does? I don't know I mean I guess it depends on how you learn best whether you learn by examples and ripping them open or learn by writing it and watching it fail I mean you can certainly with module builder generate some really simple cases like a controller class that has DI and nothing else in it and you can let it generate that and see exactly the minimum needed to inject one service into a controller class or one service into a plugin. So I guess it can help with that. Got time for one last question if anyone's got one. Nope. Okay, thank you very much for coming everybody.