xurizaemon (63f9fef6) at 17 Oct 08:31
Merge branch 'main' into 'update-composer.json'
... and 11 more commits
I revisited this extension after a few years and was surprised it had a composer.lock
committed - that's not my expectation of how an extension would work, I'd expect a single top-level .lock file which is generated for the site/project and resolves dependencies for all components in it.
To understand what's normal practice in CiviCRM space, I had a look at a handful of extensions which showed up in a search for composer.json
One had a composer.lock as well, and most didn't. So I'm filing this PR to remove composer.lock
, but I'm not in a position to test the extension, so we should wait until someone gives it the
There's also extensions-directory#9 which suggests there's not a clear rule here yet. I didn't find anything in the docs yet.
Related: https://lab.civicrm.org/xurizaemon/org.civicrm.contrib.anonymize/-/merge_requests/20
¯\_(ツ)_/¯
xurizaemon (7f90ff4e) at 27 Aug 19:41
Document a couple more alternatives
Thanks! I've added some of the more viable looking alternatives as links in the README now. I'm really happy this works for you and hope it still has something to offer, but you shouldn't feel obligated if there are better solutions :)
xurizaemon (61f66d75) at 27 Aug 19:15
xurizaemon (9e17cdfe) at 27 Aug 19:15
Merge branch 'readme-updates' into 'main'
... and 2 more commits
xurizaemon (61f66d75) at 27 Aug 19:12
Document a list of known alternatives.
xurizaemon (26488302) at 27 Aug 19:05
Explaining jokes doesn't require an h4 heading?
With reference to this wiki doc:
It currently says:
- In Github, create a new personal Github token
- In Gitlab, create a new project under your own personal project space (ex: lab.civicrm.org/janedoe/myextension)
- Go to the Import tab, then select Github
- Enter the access token
- Careful to only import the given project (do not click that tempting "import all" button)
I propose:
- In Github, create a new personal Github token, granting the repo scope.
- In Gitlab, create a new project under your own personal project space (ex: lab.civicrm.org/janedoe/myextension)
- Go to the Import tab, then select Github
- Enter the access token
- Careful to only import the given project (do not click that tempting "import all" button)
This will inorporate guidance around which permissions are required for the operation..
xurizaemon (a970fa63) at 27 Aug 06:51
Add details, license, type etc to composer.json
Composer discussion at https://chat.civicrm.org/civicrm/pl/kqhekzi3a3rz7bscgjemf6afjh & extensions-directory#9
xurizaemon (4d120c33) at 27 Aug 06:18
Add details, license, type etc to composer.json
xurizaemon (32e3a146) at 27 Aug 05:29
#17: Remove composer.lock
I revisited this extension after a few years and was surprised it had a composer.lock
committed - that's not my expectation of how an extension would work, I'd expect a single top-level .lock file which is generated for the site/project and resolves dependencies for all components in it.
To understand what's normal practice in CiviCRM space, I had a look at a handful of extensions which showed up in a search for composer.json
One had a composer.lock as well, and most didn't. So I'm filing this PR to remove composer.lock
, but I'm not in a position to test the extension, so we should wait until someone gives it the
There's also extensions-directory#9 which suggests there's not a clear rule here yet. I didn't find anything in the docs yet.
Related: https://lab.civicrm.org/xurizaemon/org.civicrm.contrib.anonymize/-/merge_requests/20
xurizaemon (909e28bf) at 27 Aug 05:28
This extension has gone unmaintained for several years! And it ships with a composer.lock
, which will be outdated I'm sure.
Do CiviCRM extensions usually ship their own composer.lock or leave it for CiviCRM / the host site to sort out?