Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#26791 closed feature request (invalid)

Rewrite Grunt to Phing

Reported by: yaniiliev's profile yani.iliev Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.9
Component: Build/Test Tools Keywords: close
Focuses: Cc:

Description

It hurts my eyes to see that a PHP based project is not using Phing.

Change History (7)

#1 @SergeyBiryukov
10 years ago

  • Component changed from General to Build Tools

#2 @dd32
10 years ago

Grunt is a pretty amazing toolkit for a build system, WordPress while written in PHP is not in the camp of saying one platform is better than another, rather, it's use the tool best suited to the job. For that reason WordPress has increasingly used more Javascript within the WordPress admin to better user experience, and through that we've amassed a lot of knowledge amongst the core contributors in Javascript.

Grunt seems like the perfect choice for WordPress with the huge range of existing modules (that cover everything from basic CSS minification, concatenation, right up to Javascript Unit tests w/ Phantom JS all in the same dependancy structure with no external configuration needed (other than Node.JS)), easy templates for developing new modules, existing knowledge for developers from other projects and workflows, and most of us already having enough JS skills to be able to do what's needed.

I was slightly skeptical at first, but I've been pretty sold on Grunt. I'm sure another build system could be customised for WordPress's needs, I'm also sure Grunt has some shortcomings, but I don't think we need to replace a well working tool just because it's not written in PHP.

#3 @jdgrimes
10 years ago

  • Cc jdg@… added

#4 @jorbin
10 years ago

  • Keywords close added

As dd32 hints at, WordPress is not just a PHP project. It's also a project that uses SASS, CSS, and JavaScript in addition to PHP. So while a good deal of WordPress is in PHP, I don't think we are a "PHP Based Project".

Additionally, most of our build process is focused on the CSS and JavaScript.

Our build process is in no ways that I can see "Broken". I also don't see any benefit to Phing that we get from switching.

#5 @nacin
10 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

#6 follow-up: @bpetty
10 years ago

It's true that the decision to use Grunt was made internally without consulting the community (no discussion about it #wordpress-dev, just an announcement on make/core, along with it's corresponding ticket, #24976). I'd be great to be able to link to an archived discussion where the pros/cons of each were hashed out before a decision was made.

However, I can tell you without a doubt that there really wasn't any point in discussing it to begin with because the majority of the community was already quite happy with Grunt (and you can see that excitement expressed in the comments made when it was announced). I can definitely also say that it fits WordPress's task requirements much more closely than we could have ever achieved with Phing, specifically without actually installing Node.js anyway for use with Phing in order to still accomplish the same tasks, but with a much less flexible task runner. It was mostly an obvious choice to begin with.

That's not to say it wouldn't have been possible to write Phing tasks to perform all of the same tasks, however, we would have been required to install Node.js anyway, and at that point, adding the additional requirement to install Phing as another dependency just doesn't make sense. It would have just been a wrapper around our Grunt tasks for a majority of them in the end anyway. That's all without even needing to even look at the pros/cons of Phing which would have included it's lack of support for flexible file mapping specifications that make our Gruntfile much more robust than any Phing tasks would have been, and much easier to read and understand.

If you still believe we should use Phing though, I'd challenge you to implement all of the same tasks we already have in our Gruntfile with Phing instead, and see how it compares yourself. If we were to even consider a switch at this point, it would require that you submit a proposed solution including a patch that not only proves it could even be done, but that it could be done better. If you really believe Phing is better suited, I'm sure this won't be a problem for you.

Feel free to continue discussing and attaching patches, but this already has enough votes to close as it stands.

#7 in reply to: ↑ 6 @nacin
10 years ago

Replying to bpetty:

It's true that the decision to use Grunt was made internally without consulting the community (no discussion about it #wordpress-dev, just an announcement on make/core, along with it's corresponding ticket, #24976). I'd be great to be able to link to an archived discussion where the pros/cons of each were hashed out before a decision was made.

For what it's worth, the decision came out of discussions at the WordCamp San Francisco contributor day. The working group was announced at the start of the day, and the group and its discussions were open for anyone there who wanted to participate. We had a lot of problems and needs; the group was tasked with identifying them and then coming up with a proposed solution. Grunt was indeed one piece of the solution, but that wasn't necessarily the goal from the onset. I wasn't involved in the conversations either, instead letting smart people come up with a proposal.

Among the committers and top contributors at the contributor day, there was overwhelming support for the proposed solutions (unified tests/src repository, new task runner and build process, etc.) and so we immediately went about implementing them. Yeah, it bypassed IRC, and of course it would have been nice if the conversations occurred online rather than in person. But, the blog post was designed to function as minutes from the day's discussions, in order to leave a paper trail. That *is* the archived discussion.

Note: See TracTickets for help on using tickets.