#30334 closed enhancement (wontfix)
New Precommit Grunt Task to avoid __DIR__ and 5.3+ stuff in Core.
| Reported by: | georgestephanis | Owned by: | jorbin |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Build/Test Tools | Version: | 4.1 |
| Severity: | minor | Keywords: | has-patch |
| Cc: | Focuses: |
Description
As was noted in [30311], a __DIR__ crept in, which isn't available in 5.2.
This sounds like an ideal case for Grunt scanning for instances in the future to prevent future 'oops' commits.
Attachments (1)
Change History (6)
#2
@
12 years ago
- Milestone Awaiting Review → 4.1
- Owner set to
- Status new → assigned
While there are a number of things we can't catch from simply scanning the code, this will help us catch some of them.
#3
@
12 years ago
- Keywords close added
Is this a good use case of Grunt? Seems more like Codesniffer or PHP 5.2 syntax checking. Though __DIR__ doesn't trigger a syntax error in 5.2, __DIR__ isn't the common issue. It's some other PHP 5.3-ism, usually, and ones that trigger a fatal or syntax error.
The number of times a __DIR__ has entered core is, best I can tell from a search of commit logs, 1.
#4
@
12 years ago
- Milestone 4.1
- Resolution → wontfix
- Status assigned → closed
I agree with Nacin. As I had mentioned in slack earlier: :At first I really liked the idea of using grunt-search, but I think phpcodesniffer is actually what we should be using in this situation. I would rather us work on getting #30153 done and then we can write a sniff for dir if one does not exist already.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
This could easily be extended to also check for shorttags and other stuffs.
https://www.npmjs.org/package/grunt-search