Comments (7)
+1 on this
from coder.
I think the suggestion 3 is the right way to approach this - build on top of drupal/coder
- ignore the irrelevant rules, tone down the ones we need to tone down, override what we need to override.
Hopefully it would make maintenance easier in the long run and also gives us the ability to easily and cleanly do things like lint extension code automatically as part of extension review processes (speeding this up is a win as we can get more extensions approved for in-app!) it lets developers pull the standards into pretty much every editor/IDE these days (the amount of faff to get these standards in VSCode is a nightmare and knocks out the Drupal standards!) but more importantly hopefully it actually makes it easier to maintain/update as we're just worried about maintaining our code on top of the Drupal coder package as opposed to maintaining a fork.
I've started working locally on detangling the Drupal specific bits and instead referencing them from drupal/coder
directly (which gets required as a dependency) - using the 8.x-2.x version at present.
Should I be rebasing this off of the 3.x.x version?
from coder.
From the change log, it sounds like the fundamental difference in 3.x.x is the target version of phpcs:
https://www.drupal.org/project/coder/releases/8.x-3.0
and of course a large number of subsequent patches to the sniffs/rules.
The main thing to look out for is the time required for balancing out the new sniffs and the code in core repos. Hopefully it can be trimmed without too much difficulty. This does seem like a good opportunity to modernize the phpcs version.
from coder.
OK, so this and #15 are closely inter-related. I'm not exactly sure if it's better to post my comment here or there.. but...
It sounds like a question of how civicrm/coder
should relate to upstream drupal/coder
, eg
- (Status quo)
civicrm/coder
is a soft fork ofdrupal/coder
. It has some opt-outs -- and we periodically merge/rebase (like once every year or so). civicrm/coder
is a hard fork ofdrupal/coder
. We can rename anything/everything, and we stop doing merges/rebases.civicrm/coder
is a separate package that depends ondrupal/coder
. It defines a separate "CiviCRM" ruleset which uses many of the sniffs from theDrupal
ruleset.
Conceptually, it seems most appealing for civicrm/coder
to be separate+dependent package. But I have no idea if that's easy or hard. (Bearing in mind that it's subjective... there's one POV for CI+civilint, and there's another POV for local IDEs.)
Relatedly, I know @eileenmcnaughton sometimes expresses frustration because the Civi+Drupal rulesets drift apart, and on the surface renaming would sorta harden that split. But I think maybe the real problem is the confusion that arises from mixing them (eg choosing the "Drupal" style in PHPStorm will give you warnings on a "CiviCRM" style codebase). So if we bite the bullet and make the split cleaner, perhaps that would address the same concern.
from coder.
Hmm - I think my concern is that I want us to be periodically increasing our compliance - ie every now & then getting us in compliance with a new rule & locking it in. There are some places (class naming) where we are legitimately different but in general the drupal rules are ones we should adhere to & it's only because we haven't made existing code compliant that we don't
from coder.
From the change log, it sounds like the fundamental difference in 3.x.x is the target version of phpcs:
https://www.drupal.org/project/coder/releases/8.x-3.0
and of course a large number of subsequent patches to the sniffs/rules.
The main thing to look out for is the time required for balancing out the new sniffs and the code in core repos. Hopefully it can be trimmed without too much difficulty. This does seem like a good opportunity to modernize the phpcs version.
Then that's the direction I'll go. Replicate where we are currently on 3.x.x in a new branch so we can test it against core code repos and see where we're at!
from coder.
hey @eileenmcnaughton @totten @homotechsual @sluc23 - interested in your thoughts on this: https://lab.civicrm.org/michaelmcandrew/civicrm-coding-standards/-/issues/1
from coder.
Related Issues (3)
- Publish on Packagist HOT 1
- Single line docblocks broken? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from coder.