 All right, how does audio sound for everyone good? Okay, cool. I will get started in just a minute My clock says it's 2 15. So let's get going Thanks everyone for coming to hear about using grunt to manage Drupal build and testing tools Before we get started how many folks have heard of or used grunt before? Awesome How many of you are using it in your daily kind of development workflow? Great cool Cool, so just to kick me off and get us started on account of three. Can you all give me your best grunt? one two three Awesome, thanks So I'm Joe Turgin. I'm a director of engineering at phase two and Yeah, I'm happy to be here to talk about using grunt with Drupal And the first thing I want to address is just you know, what is the need here? Does Drupal really need a tool for helping with this and I would say that that need has emerged as our development practice has evolved so You know, we've probably all started in with a kind of simple Approach to installing Drupal, you know downloading core from Drupal org Adding some custom code and copying that up to a server and that's perfectly fine for getting a Drupal site up But I'm sure, you know, many of you are using other tools as part of your workflow You might be using Drushmake to download corn contrib Using tools to check your code quality compiling SAS to CSS using behavioral testing and so all of those tools are adding complexity to our development workflow And so I think there's an opportunity to have a tool that helps bring all those together So just to break down also building and testing Drupal, you know, why build Drupal? And I think this is really about ending an anti-pattern of mixing your custom code With corn contrib which you're downloading from a website and creating a more consistent way of pulling all those pieces together Building also probably implies that you have something like a make file that defines the different components your project depends on And so by having that, it gives a lot of visibility into what the project is built on, what it's made up of And going along with that, I think it simplifies the use of external libraries and resources So, you know, we're not just pulling code from Drupal.org, we're pulling jQuery plugins and resources from, you know, other sources And so having something that can help pull that together helps with documentation and developer onboarding And really, you know, at the root, this is all about enforcing reproducibility and automation of your builds So that, you know, you can be sure that it's resulting in the same process no matter who's doing it And so why test Drupal? You know, there have been a lot of great sessions that have emphasized the need for testing And really, you know, I think it becomes apparent that complex sites need a lot more testing And something that's more rigorous than kind of just test clicking around on a website You can't just find all the regression issues by kind of randomly testing stuff It's good to have a script and even better to have it automated so that it doesn't take human time to verify your site is still working as expected Having tools that help with testing or code quality checks also empowers developers to build higher quality code And code that, you know, works and will continue working in the future It also allows you to find regressions or code style issues before you've committed your code You know, I think it's apparent that it's easier to fix problems when they're still in the hands of the original developer And they can kind of tweak things rather than having it already in the code base we're sharing And then it potentially causing problems for others But I think, you know, after you've adopted some of these tools in a more complex workflow I think there are a couple open questions that remain One is, how can you make sure everyone uses the same tools in the same way? And so, you know, as I've seen projects adopt some of these tools Usually you have a readme file that just gets longer and longer with the steps you need to do to get the site operational on your machine You know, steps you're supposed to do before you commit code into the repo And, you know, that can become complex and just a multi-step operation a lot to keep track of There's also an open question about how you can isolate and separate your custom source code from Drupal core From other dependencies and from the build output And so this is where I think introducing a new tool and I'm going to suggest Grunt make sense And can help with some of these connecting pieces So why Grunt? It sounds like a lot of you have used it and know about it Basically it's a simple or a general JavaScript-based task runner So it's about running tasks, running, you know, automatable tasks It's written in JavaScript Like Drupal, it's very widely adopted, it's very flexible And there's a good community of support behind it And it's also pretty lightweight in terms of only requiring Node.js So there aren't a lot of extra tools you have to introduce into your system to be able to take advantage of Grunt It also has a fairly straightforward approach where you write tasks in JavaScript And you write the configuration for those tasks in JSON And so JavaScript and JSON are already kind of part of our Drupal world So I think it's a fairly accessible tool to get into And it also has a very large library of contributed plugins And these are things that can do specific tasks for you Are out there for you to find and pull into your system So hopefully I've made a compelling case for Grunt here And if you haven't checked it out before, take a look at the Getting Started guide on gruntjs.com It has a simple walkthrough of creating a Grunt script to minify JavaScript And it's just a good way to kind of see the process of using it So today I'm going to introduce two open source tools that we've released The first is Grunt Drupal tasks And the idea here is to have a Grunt plugin that provides a good base set of common Drupal build and testing tasks So I think for this tool to be adopted and be a good value for you It's good to not have to start at a blank slate with Grunt But to build off of things that kind of try to capture some of the common Drupal development tasks And so this is something I started as a R&D project last January Around this time of last year, several Face2 client projects had already adopted it and started using it We released it as open source on GitHub in September And since then I've talked about it at Bad Camp and some other camps And just this spring we achieved kind of dual support for both Drupal 7 and Drupal 8 Which I think is an important milestone and will allow this tool to support Drupal 8 So a couple things about Grunt Drupal tasks It does have some opinions about how you should structure and do your work And the idea there is to enforce a common practice across the team And also be able to share that automation with a continuous integration environment So you know all your teammates are kind of using the tools in the same way And you can also produce builds in an integration environment That will have the same output you expect and see on your local environment It does have a couple assumptions about what your kind of development workflow and code workflow are going to be Basically that you want to verify the quality of your custom code Using linting and other static quality tools That you're going to assemble your core modules Core and contrib modules and themes using something like Drushmake to pull them all together And then you're going to run tests on the site It also introduces the concept of a project scaffold for Drupal So you can imagine that if you're working on a house, say painting a house You want to build a scaffold around it to be able to give you access to that work site To have a place to put your tools And in a similar way the concept of scaffolding has emerged for web projects Where you have kind of some room around what the primary code is to be able to store tools And just have things work together So this leads into bringing a lot of tools that we do use in our practice together And so we see Grunt and Drupal Grunt being able to help you use things like the hat and compass and pattern lab And it really helps trying to orchestrate those tools and make them work together consistently We also wanted to build it with some sensible defaults so that this could be used out of the box But also aware that our assumptions might not work for everyone So allowing you to customize and override some of the configuration And I'll show more about that later It also tries to manage its own dependencies I've talked about these other tools like compass and behat that it will help you use And it also helps you install those and set those up So that these tools are ready to use and they're discoverable There's one tool that can kind of lead you to the other tools You don't need to know about all the tools individually At first it kind of brings that together and gives you a single point of access The other open source project I'm going to introduce is something called Gadget And this is simply just an easy way to start a Drupal project using Grunt Drupal tasks It's a yeoman generator which is another tool in the kind of Grunt yeoman Bauer universe And basically it's about setting up a project skeleton So this is something you use once to set up a project And then from then on you can use just Grunt And this is something we developed recently just to simplify the process of setting up a project with Grunt You can do it without Gadget but this is a nice way into it And I'll show you that in just a minute So let's get started and look at what it looks like to use Grunt Drupal tasks And how you get it set up And just to note the dependencies Before starting you'll want to make sure you have Node.js installed That includes NPM which is a package installer for Node And then there are a few other tools that we recommend If you want to use that kind of universe of tools I mentioned before And that includes having Bundler, Composer, Ruby and RubyGems installed So to get started with Gadget There's one command that will install the Gadget generator on your system It'll install it globally so you just have to run this once on your computer And that installs Gadget and its dependencies And once you have Gadget installed, you can create a new Drupal project Using GruntDrupal tasks by running yoGadget Yo is kind of the common command for starting a yeoman generator And when you do that, when you run yoGadget, this is the output you'll see at first A nice little ASCII art image Well-communicated to GruntDrupal tasks And then asking which version of Drupal core do you want to use And this prompt interface is one of the big values of yeoman Giving you the opportunity to start a project Specify a couple of preferences about what you're trying to do with that project And then it'll create a skeleton for you to start The first prompt that we've implemented is Drupal core Do you want Drupal core 8 or 7? Let's say you pick 8 It lets you know it's going to start assembling this project for you The first thing it does is install the latest version of GruntDrupal tasks And then it sets up a drushmake file to download Or install the latest release of either Drupal 7 or 8 You'll see it reports that it's creating a bunch of files It installs some dependencies for that And then it says it's ready to run the first build of the project So let's take a look at what Gadget created for us Which is this project scaffolder skeleton And this is assuming you've run it in an empty directory This is what you'll see then, these files that have been created for you And I'll just step through some of these There's two files that start with Grunt, GruntConfig and GruntFile And this is a project-specific script and configuration So this is where you can override and customize what Grunt is going to do And I'll talk about that more near the end There are also a couple JSON files, Composer and Package Which define dependencies for GruntDrupal tasks And you can also use these to include dependencies for your project So you might be pulling in some PHP components You could add those to this Composer And GruntDrupal tasks will help install those for you There's also a node modules directory And just for those of you who are not familiar with Node This is just where Node stores its module So this is just dependencies for GruntDrupal tasks What I think is getting into the more interesting Drupal part of this Is the source directory, SRC Which stores all the custom Drupal code, DrushMake file And other components you need to build your Drupal site And we'll look at this in more detail in just a minute And then finally, a test directory Which contains a behat config file And space for you to put behat test features So if we look into the source directory This is where you'll see a lot of common Drupal elements There's a space for modules Where you can put any custom modules for the site A space for profiles Where you can add installation profiles A DrushMake file A sites directory that can store Your single site config Sites default Or multi-site configuration A static file directory Which allows you to put any static file replacements So if you want to override the default Robots.txt that's installed Maybe add a humans.txt Up to you, you can place that in static And GruntDrupal tasks will take care Of putting that in the right place for you And then themes Which you can include any custom themes for that site So the goal of this kind of project skeleton And scaffold again Is to accommodate all the custom code Make files, site settings files And tools that you have But also isolate them from Drupal Core and Contrib And this allows you to Allow tools to work together with minimal glue One of the reasons you want to isolate your custom code Is you can run code quality checks just on that You don't necessarily want to know how good The code quality of Drupal Core is You want to focus on your custom code Which is what you're working on And by having a structure That kind of accommodates all the different components You might need for a Drupal site We can standardize on this as our Basic project code base structure And this can be what you then check in To your Git repo or other version control system So I'll move into the build process Which is really at the heart of GruntDrupal tasks And once you have this project skeleton set up You can use Grunt to build the project Just by running Grunt And that invokes a series of build steps Which includes running Composer install Optionally Bundler install To pull in any dependencies you have From those systems Running code validation Running Drushmake Doing the scaffolding to inject your custom files Into the build output And doing any theme compilation you have Like compiling SAS to CSS And I'll just note that Not all of these steps are run Every time you run Grunt It's run when it's applicable or needed So every time you run Grunt It's not going to do a full Drushmake It'll only run Drushmake if it sees that Your make file has been updated More recently than the build output So it tries to be smart about what to do And so here's just an example Of the output from running Grunt We'll see it start And run Composer install And some of the things you'll see Pulling in here are dependencies for Bahat It will run Drushmake And pull in Drupal core And also any contrib modules Or themes you've defined And then it does the scaffolding task To integrate your custom code With the build output So if we look again at that project Directory after running Grunt We'll see a couple things have been added here Most notably the build directory Which includes a couple of directories And I'm going to focus on the HTML directory Inside of that Which if you look inside of that You'll see something that looks like A common Drupal doc root Essentially what you get by downloading core And extracting it And I'll return to that in just a minute But I want to also point out There's a vendor directory which includes Some of those project dependencies That would be pulled in from the Composer JSON And that includes Bahat Composer which is actually Pulled in by a gem file And other supporting tools So if we look back at the Build HTML directory Again this is basically A Drupal core checkout But if we look into the Directories you'll start to see Things have been pulled in by Drushmake Or and or by the The scaffold task So if you look in modules You'll see a contrib directory Which includes Devel Which is pulled in by Drushmake But the custom directory here Is actually a sim link Back to the project Directory source modules Directory Similarly if we look in profiles We'll see a sim link of Any install profiles that you Included from here In the Drupal doc root Back into your source profiles Directory Likewise the sites directory Has a sim link from default Back to source sites default And some files in here May be pulled in from Source sites so you could Drop in a sites.php file Into source sites and that'll be Pulled in here And then finally themes Again like modules you'll find In the directory that has Anything pulled in by Drushmake And a sim link From custom back to Source themes And this might strike you As odd or interesting That we're using sim links here The real advantage is that You don't need to rebuild After every change you make To a source file so if you're Working on a module under Source modules as you're Apparently included in your Drupal doc root so Yeah you don't need to go through Kind of a big rebuild Of the system as you're doing Just code changes The sim links are Set up by the grunt Drupal task build task So you can be assured That they're set up correctly This is a manual task you have to do And the links Are relative Within this project scaffold Which means you can copy That whole project to another machine Whether it's a VM Locally or a server And those links will continue to work Because they are relative Within that structure so they're portable Tools like xdebug Can work across the sim link So you could be tracing and stepping Through code that's in core Contrib and then see it Kind of jump over into a custom File it's not an issue For xdebug or ids The one caveat though is for windows Users sim links are Not as well supported there And so Kind of the two options That we know of right now Are doing development on A windows machine in a virtual machine That's linux powered Or We're also thinking about Implementing an alternative to the sim link Which would be copying files Into the doc root That eliminates kind of the advantage Of the sim link so that's not something We want to do by default but For those who are developing Our windows systems that's Probably a kind of key way to move So one other thing I'll point out as part of the build process That we get by using grunt And this is similar To kind of compass watch Is you can have it run Things automatically when file changes Are detected so You can run grunt watch And that will run The Typical build tasks When it sees files being updated So just to show that If you run grunt watch You'll see it immediately say it's Waiting if you change a file Like a module file it'll Pick that change up and then Run the tasks configured And so here we see Giving you some code quality Output And then it returns To kind of a state of watching Now for the next change So this build process Is really the core of Grunt Drupal tasks we See it as capturing the Typical steps in a daily Development workflow And the purpose of it Again is to produce a complete Doc root from custom source Files and a make file And this is a process that We assume you're doing locally Building on your local machine And also doing that build process On your integration system So you're not having to Commit the build output into Your source repository Instead you're counting on that Being regenerated through the build Process on your different environments That said you can Build process and run Some of these build tasks individually So I'm going to look at And kind of walk through Some of these core tasks The first again is Validating code quality And again this is using lints And static code analysis to Try to quantify code quality And right now this is Running PHP lint and PHP code sniffer with Drupal's coding standards By running grunt validate PHP lint is just a basic way Of verifying the syntax With a built in lint tool to PHP And so this will catch Just basic parse errors, things that If you try to go on the web browser And check out the Drupal site You'd probably have a white screen of death If you had issues like syntax errors It's nice to be able to just Get this feedback immediately on the console Before having to move into A web browser Or some other place to test it Additionally PHP Code sniffer Verifies code style According to Drupal's code standards So very much like the Coder review module This is giving you feedback about White space issues Common issues Other kind of Drupalisms And again it's nice to have This output just Through a simple quick tool rather than Having to go into UI Or web perspective to get that And so having these tools Accessible through grunt Drupal tasks I think really Helps encourage developers To validate code before committing And that means that Peer code review that you might do Through like a pull request system Can focus on architectural issues Or high level issues And you're not distracted by Code style or other Issues that probably could be caught In more simple ways This can also let you Do kind of more advanced steps Like having Integration builds Automatically fail at certain levels Of Certain numbers of code style issues You could reject pull requests Automatically if it has X number of code style issues To try to really enforce Certain expectations Around code style So another major task Provided by grunt Drupal tasks Is theme compilation And You know I think it's Interesting to note that We have been using non-php tools In Drupal development For a while now I think Compass was one of the first ones That I was aware of Kind of brought into Drupal practice And So This was definitely a goal to Support Compass and Theme compilation as part of The grunt Drupal task build process So we allow you to Configure grunt Drupal tasks To define the themes you have And then what approach Should be used to compile Those theme assets And this task again can be run Individually with grunt Compile theme The one approach we have supported Right now is with Compass And if you include a gem File in your project repo Grunt Drupal tasks will install Compass For you and any of the required gems To support that And then Compass compile Is run as part of the build Process and again it can Also be run individually Through grunt with this compile Theme task and The output you'd see there is pretty Often Compass compile directly This though could be configured To compile several themes If your site has several themes So it has Some advantages to that layer Of abstraction A feature that is It's currently in pull request And we're eager to merge it In the near future Is allowing grunt Drupal tasks To delegate theme compilation To themes that are powered by grunt So this is something I think We'll start to see more of That a theme will actually supply Its own grunt file To do certain automation for it Which could be Minification of CSS and JS It could be doing the sass To CSS compilation It could be Generating sprites from individual icons So I think this is going to be Kind of a growing Space and We're excited to Provide The functionality to support that The kind of last Major piece of Building and testing is Testing and specifically Testing site features And So currently the test suite That we're supporting Is behat which is Someone of the de facto Drupal test suite Testing functionality Grunt Drupal tasks Out of the box we'll Pull in behat the Drupal extension For behat and some of the other dependencies Like mink But one note is that Testing with behat Expects not only a Drupal code base but an installed Drupal site and also one that's Successful by URL I just want to speak quickly about Two options for running Tests locally Of course you can set up a local environment Which might be a VM or using docker Or something like map on your host Machine But another interesting one For doing kind of quick and simple tests Is using PHP's Built-in web server And we've Implemented this in Grunt Drupal tasks And actually whenever a new code Is added to Grunt Drupal tasks We have Travis CI set up To run through these tasks So it's actually on Travis Spinning up a Drupal site Installing it, running it Using this system and then running Some tests against it and that helps Us verify that as we're changing Enhancing Grunt Drupal tasks We're still providing that core Functionality. So just to kind of walk through Using this, if you run Grunt Drush light install It creates a SQLite database file Installs Drupal into it And it lets you know you've got Installations complete And here's the admin username and password Another command Grunt Drush run server And both of these are essentially Just lightweight wrappers around a Drush command invokes Drush to use A database built in Server And once it lets you know That it's listening and ready You can go over into a web browser And hit your local Drupal site And so that then lets us get Drupal running locally in a Pretty simple and lightweight way And that then lets us Use the hat test against it And so now we can run Grunt test With the hat And show you the output And this could be very similar to Output directly from the hat Where you'll see it Stepping through the scenarios That you've defined Walking through the steps And then finally reporting It found three scenarios Three of them passed So that's great, our tests are passing So Grunt Drupal test is Trying to kind of encourage Towards BDD Behavior driven development Or test driven development And it's meant to support That type of a workflow Where you're first writing tests And then you're iteratively Writing code to try to pass Complete a feature that Passes those tests And you can automate this Whole process using watch Where again you can Start the watch up And then you just fail initially Then go write code And kind of have a feedback cycle Of writing code Seeing the feedback of those tests And then continue to write code And essentially writing code Until all of your tests pass At which point you know your feature Is done and working And so In support of this Grunt Drupal test bundles Some of those tools Which will run against A vanilla install Of Drupal 7 and Drupal 8 To help you kickstart testing Because we think that if you have The tool set up You're able to see that Basic tests can pass against them That'll lower the barrier of then Writing your first test against Custom code that you're working on So this is kind of edging us It's walking us through the development cycle And At the end of that The elephant in the room Is how do you get that up on a server How do you push it out and deploy it And We really see grunt Drupal tasks And this project scaffolding As being primarily meant For local and development And integration environments I'm not going to suggest that You have that kind of sim link Structure up on a live production system Not that anything would be Particularly wrong with that But it's much more Suited for local development So grunt Drupal tasks is about It's focused on preparing Code for release And then handing that code off To other tools to actually perform The deployment But there are A couple ways that grunt Drupal tasks Can help with this One is What we call packaging Really just means producing A standalone deployable Drupal doc root And that means primarily Kind of stripping out Some of the supporting tools and configuration You don't necessarily want to push The hat and composer Up to your production box You probably just want that Drupal doc root It will also De-reference the sim link So essentially copy the custom files To the doc root So you'll have just a simple Drupal doc root What you're already used to working with And you can Build this just by running grunt package Which kicks off You know Generating a tar ball and then compressing that And so you wind up just with A zip tar ball Of your build output We are exploring a couple other ways That grunt Drupal tasks can support The release process We have two approaches in mind One Is And this kind of falls within the Model of Aquian Pantheon's Hosting environments where they expect That your release code is going to be in a Git repository, but they do Expect a certain structure Which is somewhat stripped down They wouldn't want to see all these Supporting tools there So on a couple client projects that we've done With Aquian Pantheon We've done some project specific Scripts to Pull your kind of package Code out of the project repository And push it into another repository And Have that prepared for deployment And this is something That we'd like to pull back Upstream into grunt Drupal tasks Because I think it would be useful For others and Frankly we'd like to have it As a more general function for future Projects ourselves And I think there's also room to look at Integrating with other tools that really specialize In release and deployment Like Capistrano or Shipit So That's taken us through The kind of tasks and functionality That you get out of the box with grunt Drupal tasks Those are really the core functions And what we think Works for The vast majority of projects As I mentioned we do want to support Variations and using Grunt Drupal tasks in different ways And so I'd like to just talk quickly About configuring and extending This Configuring By that we mean Changing settings that we've decided To expose in gruntconfig.json So again this is a json file That Has different settings that grunt Drupal tasks uses That allows you to modify What it's Expecting So a couple of the settings you can change Are the source and build paths So I talked to There are assumptions about That project scaffold but you can Tweak exactly how that's set up You can change some of the Command line options that are sent To behat so you can For your project if you have a certain Say tags that you want Run in behat you could put that in Your gruntconfig.json file You could add custom Arguments to drushmake If that's needed for your process Again there's options about How you're compiling your theme And also what Files to include or exclude from The package script And so just a quick example Of a configuration let's say You want to add the working copy flag To drushmake whenever that runs This is just a A quick image of Showing the gruntconfig.json file With some arguments Added to the drushmake process And additionally if you want To get deeper into changing how GruntDripleTask works you can extend It and these extensions Mean that you're altering Your project's specific Grunt file and Changing the tasks That are defined and this Allows you to add new tasks Replace existing ones You could Have a shell script Maybe that you want to be run As part of the default build process And you could add that to GruntDripleTask through these extensions You can also override The default steps in the build Process to tweak it as you Needed So for example Let's say you want to add A grunt plugin Say the eslint plugin for doing JavaScript lint team It just takes a couple lines of code To load that grunt plugin Configure it to Lint the JavaScript you want And then add that to The default build process So to wrap up I hope this has been Informative and interesting I think that I'd love it if you're interested In using gruntDriple tasks On your next project Checking out the gadget generator For setting up a new project With gruntDriple tasks And then using gruntDriple tasks In your daily development workflow Building and sharing this With others on your team If you have ideas on how This could work better Please file some issues In the github repo And patches are always welcome About this we've been getting Contributions from the community And that's awesome And I'd love to see more people Pitching on this project And We've also labeled some tasks Or issues on github As help wanted And we see these as good tasks To kind of get your feet wet And step in and help out the project So take a look for those On the github issue queue And just to give you an idea Of some of the things that we're planning For future development We'd like to support more quality And testing tools, and that could be SAS or JS linting It could be adding support for PHP Unit, especially for Drupal 8 As I mentioned before Allowing delegation to grunt Powered themes for doing Theme compilation Adding more options for Releasing and deployment There's some interesting discussions Around using Composer for building Drupal instead of Drushmake And that's something that we would like To move quickly to support I'm also really interested In Drupal console Which I think can offer Some ways to automate common Development practices And I think it's a no-brainer To introduce that into the Grunt Drupal task universe And then finally Adding more options and prompts to Gadget To let you configure and choose And specify more of the preferences You have about how you want to set up Your Drupal project So thanks very much for coming I'm going to get The slides for this session up on The session page on The DrupalCon LA site Here's just a quick link For reference It'd be great if you could evaluate the session Check out the slides there I'll also put up links to The different projects and resources I mentioned So thanks very much And I'm happy to take any questions you have I have a question If you have an existing project Is this something you shouldn't do And it should be only for new projects pretty much It's easiest to do with new projects But I have Tried kind of converting Old projects into it And it's definitely doable And it's easy to confirm Whether you've done it successfully Because you can Configure a project along these lines Put your custom code in Run build and then compare That build output with what you currently have So it's Not impossible but just kind of difficult Yeah I mean it's You probably would want to have a reason For doing it, I mean if you want to If this makes sense as a way To tie some of those tools together for you It might be worth that Kind of one time effort to Pull your current project into this Thank you Yeah This is with regard to the SimLinks for Windows development Is there a reason why not to use the Windows SimLink for it I'd be curious to hear more about that I Have heard There might be issues with SimLinking Directories So if you have more information About how to implement that That would be an awesome contribution Okay First off kudos It's an absolutely amazing thing We have something internally In our group that's very similar But not nearly as standardized And Not pushed out for everyone In the world to share in But one thing we do that I'm wondering If this would work with Is all of our custom projects Get repos Is there an easy way To integrate that into this workflow Could you say more about that Rather than having a Single repo That's all of our Themes and module All of our custom themes and modules are in Each of our custom themes And modules has its own repo And we're currently using Drush To bring those in as well Yeah I think that's an option And there's definitely a balance Of whether you want to have all those custom modules Living in their own repo or in a common one This approach Is Would work equally For either The approach of using Drushmake To pull in those custom modules From Git repositories Makes sense in this workflow Cool, thanks I was wondering if you compared Grunt To other older tools like Fing for example Fing You know Fing? Why Grunt was chosen The main advantages of that Yeah So we actually had a build Tool Using Fing before Grunt I mean I think So one advantage to Fing Is that it's based in PHP So it's a little more In our community But And it can work for some of the Basic file manipulation And kicking off other tools It doesn't have the same library Of plugins that Grunt has So it doesn't have the plugins For doing JavaScript minification And CSS It doesn't have all those tools And it doesn't have the same kind of momentum That Grunt has behind it We chose Grunt to Yeah because It is widely adopted And has a lot of momentum right now So we felt like it was a better Option for the long term at this point And second part Is you use Grunt to do your local Code analysis and verification as well Most of our developers prefer to do that From within their IDE So when they save a file for example Code sniffer is run, linting is done And they get the feedback right away Do you consider that option or use that as well? What is it actually running The lint in that case? I think it's just configuration Most of them use PHP Store Just configuration in PHP Store May say these tools have to be run On each save for that type of file So I'm not sure exactly having configured it To document it better but It's something like that Yeah I've seen people use Say the watch task Maybe if you have kind of a shell You know Window within your IDE You could use the watch task there And be getting the feedback from Grunt I mean I think The advantage using Grunt over something Like PHP Storm is just that You don't have that extra overhead Grunt can be run on the integration Server where you probably can't You're not going to run PHP Storm And it's linting on your integration Server so it's Okay the portability but the one advantage They mentioned is the fact that it shows The exact line where the error is shown Within PHP Storm and you can jump to it Automatically as well for example Yeah that's true Yeah thanks When you're using Grunt and it's downloading assets Like Drupal or the contract modules Does it cache those locally So it doesn't re-download them Every time you run built Yeah The dependencies for Grunt Which are like no dependencies NPM does some caching of those Drushmake I believe does Some caching of Drupalcore and Contrib but it's Not always as aggressive as I want it to be So That's one of the reasons that we're not Running Drushmake on every run of Grunt We only run it when we see that the Makefile has been updated Because downloading core Contrib can take a while And so just to keep the process You know quicker Yeah we try to do that only when it's Necessary Because I've run into similar Build time issues When doing building from a Makefile I thought there may Be some magic to cache that stuff Locally Sure In my experience Git does not follow Simlinks So if we're going to put The repo in the src folder How about those modules that are Sitting in the project route and you Said pantheon and all those guys Don't accept the whole build tree As a part of the repo so how do we Overcome that with two repos or what do we do Right yeah so with A kind of say pantheon model Yeah so far we have Used two repos so we have a repo For the project Which again just has your tools And your source custom source code And then a repo for the Fully built product which is Deployable And you know there's Some disadvantage to having Two repos but It does work cleanly and You know there's a clear purpose For both of them Cool thanks great alright well Thank you everyone I'm happy to Yeah take any other questions up here Thanks