Update external barcodes library tecnickcom/tc-lib-barcode

Nice work. A couple of comments.

I think to do this we should bump the release number of the Barcodes module, since we're dealing with a backwards incompatible change. Hopefully we can get away with a minor point release and not have to do a major point release - I would have to research the Drupal guidelines for this. What I am concerned about is because this is an incompatible change, updating the module with drush or the Drupal UI won't work. Or rather the update *will* work but the library won't get updated this way so the site will crash when Barcodes is used next. With this change, the new library has to be installed via composer, which may not be a typical workflow step.

@todo The project page will also have to be updated for the new barcode types.

I see you made changes in the README like this:

-* C39E: CODE 39 EXTENDED
+* CODE 39 EXTENDED

Aren't the array indexes still relevant (albeit only for programmers) ? We also use the array indexes (e.g. "C39E") to map CSS libraries to the barcode type, so even for someone who just wants to figure out how to style a particular barcode type, the index is useful.

Is there a need or use case for adding barcode.html.twig?

Thanks for the feedback.

#4.1 We should bump the release number
The recommendation to install the module on the project page is composer require 'drupal/barcodes:^2.0'.
As per semantic versioning we should bump
* major in case we make incompatible API changes.
* minor in case we add functionality in a backward compatible manner

As we do not expose the library as a public API, I see no point in bumping major, unless we break sites if we don't.

Given constraint of ^2.0 as recommended on the project's page and semantic versioning

A minor version bump:
* bumping to 2.1
* composer update will update the module, as well as the library
* drush or Drupal UI will break the site as the library will stay outdated

A major version bump:
* bumping to 3.0
* composer update will update neither the module nor the library
* it will therefore be a more conscious process to upgrade
* updating manually with drush or Drupal UI will break the site as well

As the initial install of the module needs to be done with composer require already - for getting the library and generating the autoloader - isn't it safe to assume any updates will be done that way?

#4.2 The project page will also have to be updated for the new barcode types
Added the todo to the issue summary

#4.3 Aren't the array indexes still relevant
I agree, readded the barcode identifiers to the docs, but behind the description for better readability.

#4.4 Is there a need or use case for adding barcode.html.twig?
Drupal 10 was trying to fall back to it when it didn't find the specific template for a new barcode type.

TR → changed the visibility of the branch 3419473-update-external-barcodes to hidden.

Updated MR to apply to 2.1.x.

Just a minor comment: Shouldn't tecnickcom/tc-lib-barcode be listed on the project page to give proper credit?

Automatically closed - issue fixed for 2 weeks with no activity.

@hansfn: Thanks for the suggestion. I have done that on the project page and the documentation guide and am working on updating the README. I also changed the project page for the similar modules, to mention which external libraries they are using for comparison.

I think drupal.org should probably have a place on the project page that modules can use to list their external dependencies - right now as far as I can see very few modules do this. This info could probably be generated automatically by looking at composer.json - that would go a long way to ensuring the Drupal community gave due credit to other open source projects.

Thx, TR, for actually responding to my comment - I appreciate it.

Yes, listing external dependencies on the project page automatically based on the composer.json file would be nice.