chx
Repos
64
Followers
80

Events

opened issue
Maybe mention chromedriver and xvfb-run?

I found xvfb-run chromedriver --port=4444 to work ... where google-chrome-stable --headless did not. I am not expert on this, I am just reporting and asking: would this be useful in the documentation?

Created at 3 days ago
pull request opened
Update service_decoration.rst

Note service tags.

Created at 2 weeks ago

Update service_decoration.rst

Note service tags.

Created at 2 weeks ago
Created at 2 weeks ago
issue comment
xdebug is gone when using drush launcher

Please see the screenshot. I tried the environment variable.

Created at 1 month ago
opened issue
xdebug is gone

2022-08-18 23_27_37-Window

drush --version
Drush Launcher Version: 0.10.1
Drush Launcher Version: 0.10.1
Drush Commandline Tool 10.6.2

I have no idea what happened here. This used to work.

Created at 1 month ago
delete branch
chx delete branch patch-1
Created at 1 month ago
pull request opened
Crosslink COMPOSER_NO_DEV

The COMPOSER_NO_DEV option is relatively hard to find, let's make it easier.

Created at 1 month ago

Update 03-cli.md

Crosslink COMPOSER_NO_DEV

Created at 1 month ago
issue comment
No error message for $settings["config_sync_directory"] missing

Smells like drush to me.

In FindCommandsCompilerPass there's a [new Reference($id, ContainerInterface::IGNORE_ON_INVALID_REFERENCE)].

Created at 1 month ago
issue comment
No error message for $settings["config_sync_directory"] missing

So ... trying to initiate the config.storage.sync service will throw an exception and indeed the import command depends on this.

The question becomes then, what catches this exception? It showing up would be the very error message message missing here. And, this might mean there's a much wider bug here of something catching an exception that would be better shown? At least in verbose, if it is desired to silently just not show commands which can't be made.

Created at 1 month ago
issue comment
No error message for $settings["config_sync_directory"] missing

Oh yes it does. drush status show full bootstrap, drush php runs fine, almost all Drupal pages load fine. Except the config sync page.

Created at 1 month ago
opened issue
No error message for $settings["config_sync_directory"] messing

Describe the bug

I am debugging a new project and they didn't send a settings.php and the one I put together accidentally ommitted $settings["config_sync_directory"]. drush simply omits the config import and export commands and there is no error message anywhere. I only realized when I gave up and went to /admin/config/development/configuration in the UI.

To Reproduce What did you do?

Oh dear, what have I done, yeah, that's what I am asking myself in the long lonely nights. But in this case see above.

Expected behavior

Maybe something in drush status?

Actual behavior What happened instead?

drush config:import is just missing

Workaround Is there another way to do the desired action?

Not really.

Created at 1 month ago
issue comment
Should I commit the dependencies in my vendor directory?

I use composer require, of course, in fact, I never use composer update itself exactly because of this, however that only works in the simplest of case: when there are no dependencies needed to be updated. The moment you do need to update, you do not really have any options afaik because composer require -W will do a maximal and there's no "install this package, fix dependencies if needed and stop" option.

Created at 2 months ago
issue comment
Should I commit the dependencies in my vendor directory?

composer require locks all existing packages by default.

2022-07-06 21_49_16-fortepan – UploadForm php

Created at 2 months ago
issue comment
Should I commit the dependencies in my vendor directory?

I needed to think quite a bit here and now I see clearly the problem is quite big: we have a very different world view.

Mine is bitter and pessimistic: software upgrades are a problem. You want to do them sparingly because any time you upgrade software it might introduce bugs and more regression testing is needed. Why change what's not broken?

The worldview of Composer is a cheery one. Semver makes software upgrades harmless. No problem with upgrades. This worldview is well visible from the fact that anything you do with composer will do a sort of "maximum run" where just touching a single package will upgrade quite a few others.

Because of this, your vendor directory changes often where mine does not.

Perhaps two documentation pages here reflecting these world views would be better -- and also, perhaps some command line switches to composer as well to restrict it to a minimal run?

Created at 2 months ago
opened issue
Should I commit the dependencies in my vendor directory?

https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md is misleading and as shown in the recent plugin catastrophe leads to broken builds.

Let's go step by step:

The best practice is to then have all the developers use Composer to install the dependencies.

This has multiple problems: a) everyone on the team now needs to have and use Composer. That's very often unnecessary if this guidance is not followed b) it's slower than git. This is not to diss on Composer, it has made great improvement in speed but beating git is beyond what any PHP script can possibly do.

Similarly, the build server, CI, deployment tools etc should be adapted to run Composer as part of their project bootstrapping.

This can break the build when a) one of the repositories being pulled from is unresponsive b) one of the repositories being pulled from has a malicious attack c) composer itself breaks (let's hope this one doesn't happen again any time soon).

Large VCS repository size and diffs when you update code.

Disk space is, by and large, free. Although this was not Jim Gray's seminal 2006 (!) presentation title, the rule of thumb for long has been "Disk is the new tape". Most of composer managed files are text anyways. git has added pathspec magic :(exclude) and its short form :! in 2014, so excluding vendor from diff is trivial. And you actually might need to diff vendor code -- what if your bug is actually in vendor or it's an interaction with vendor code? It's not magic, it's just software. It has bugs. (Sometimes, it's my code. Of course it has bugs.)

Duplication of the history of all your dependencies in your own VCS.

This is again at best a half truth: only the tags you are actually using will be duplicated. Not every commit, not every branch.

Adding dependencies installed via git to a git repo will show them as submodules. This is problematic because they are not real submodules, and you will run into issues.

Yeah, just remove .git before adding them. Next time composer runs -- which will be infrequent anyways after this -- it will just clone from git anew. To quote my own composer.json:

"scripts": {
    "remove-git-submodules": "find vendor -type d -name .git | xargs rm -rf",


                                
Created at 2 months ago
issue comment
Consider disallowed plugin a fatal error

I absolutely see the point that if you haven't run any Composer update in the last 6 months

composer 2.2 was released on 2021-12-22 you gave us six months for the composer upgrade while not having any reason whatsoever to upgrade it. My local simply wasn't, the version my provider runs was.

Created at 2 months ago
issue comment
Consider disallowed plugin a fatal error

The solution is to version composer.json

Old versions behave as if composer config allow-plugins true -n were run.

New versions get security hardened. composer create-project creates such.

I believe currently composer.json is not versioned, a default takes easy care of that.

This allows future such changes not to break everyone's builds silently on a long weekend , one of the largest holidays in the United States...

Created at 2 months ago