feat: Add forbiddenBarcodeTypes property

[IlyaPasternakAmitech]

🎯 Summary This PR introduces a new prop forbiddenBarcodeTypes, allowing developers to specify an array of barcode types that should be ignored during scanning.

🐛 Problem In scenarios where multiple barcodes are present in the camera's field of view (e.g., a QR code with advertising data and a product barcode), only the first detected barcode is passed to the onBarcodeRead callback. This often results in missing the desired product barcode, which appears later in the detection sequence.

✅ Solution The proposed solution adds a new optional prop:

forbiddenBarcodeTypes?: CodeFormat[]

When provided, this prop filters out any detected barcode whose type matches one of the values in the array before invoking the onBarcodeRead callback. This allows developers to skip irrelevant or unwanted barcode types (like advertising QR codes) and wait for the correct barcode to be scanned.

📚 Documentation If this change is accepted and considered valuable, I'm happy to update the documentation with:

• A detailed description of the forbiddenBarcodeTypes prop
• A usage example
• A list of common barcode types users may want to filter out

Just let me know!

[scarlac]

Hi @IlyaPasternakAmitech I really like this idea, however I think the best use case would be the reverse - an allow list. The issue is mainly that as we add features, including bar code types, devs have to increase the list of blacklisted codes, if they don't want to search for them. This means existing apps can break as they upgrade minor versions, based on the same use case you outline (multiple codes in the same view).

So the suggestion is simply to flip the behavior, so instead of: forbiddenBarcodeTypes?: CodeFormat[] it becomes: allowedBarcodeTypes?: CodeFormat[] If the array is left empty, all codes, current and future ones, are allowed.

The benefit is that it's also easier to achieve faster QR code scanning, as you can simply state which codes you want supported, and then it only spends time looking for those.

What do you think?

[IlyaPasternakAmitech]

Hi @scarlac, thanks for the feedback!

I understand your point about using an allow list approach (allowedBarcodeTypes) — it makes sense in many cases and could help avoid issues when new barcode types are added in the future.

However, in my use case, I find the blocklist approach (forbiddenBarcodeTypes) more practical. Here's why:

🔍 Use Case: Filter Out Only a Few Specific Barcode Types In our app, we want to scan only product barcodes, but often there are advertising QR codes in the same field of view.

Using a blacklist allows us to simply block those unwanted QR codes, while still detecting any other barcode type that may appear — without having to explicitly allow each one.

With an allow list , we would have to specify every single barcode type we support (e.g., EAN13, UPC_A, etc.), which is less flexible and harder to maintain.

🔄 Proposed Solution: Mutual Exclusivity Between Both Props To make this work for both use cases, I propose allowing either forbiddenBarcodeTypes or allowedBarcodeTypes, but not both at once.

This way:

Developers can choose whichever fits their use case better. We prevent ambiguous configurations. The logic remains clean and predictable. Example usage:

// Option 1: Block specific barcode types
<BarcodeScanner forbiddenBarcodeTypes={['qr']} />

// Option 2: Allow only specific barcode types
<BarcodeScanner allowedBarcodeTypes={['code-128', 'code-39', 'code-93', 'codabar', 'ean-13', 'ean-8', 'itf', 'upc-a', 'upc-e', 'pdf-417', 'aztec', 'data-matrix']} />

If both props are provided, we can throw a runtime error or ignore one of them.

[IlyaPasternakAmitech]

Hi @scarlac,

I’ve updated the PR based on your suggestion — I changed the logic and replaced forbiddenBarcodeTypes with allowedBarcodeTypes. The new prop works as we discussed: if provided, the scanner will only recognize the specified barcode types, making scanning more precise and future-proof.

Also, I’d like to remind you of my previous proposal to support both approaches using two mutually exclusive props — either allowedBarcodeTypes or forbiddenBarcodeTypes. If you think that would be useful, I can implement it in a separate PR.

If these current changes look good to you, feel free to merge them. I'd love to hear your thoughts!

Thanks!

[IlyaPasternakAmitech]

@scarlac and @DavidBertet,

I would like to express my gratitude for your valuable feedback and suggestions.

Thank you, @VishaKsu, for updating the pull request.

Thank you all for your patience and valuable contributions.

[scarlac]

The PR was in bad shape. It did not compile on either platforms, and there were several issues around how the props were handled, as well as which codes were supported. I've fixed them and will merge the PR.

Unfortunately, this will be the last PR that we will be attempting to accept (ie. make changes to and then merge) with a high amount of "vibe" AI use. We need contributors to full understanding their code, as the point of accepting PRs is that the maintainer(s) is unburdened. If we end up having to fix issues in code we don't write, before the PR merges, then the point of accepting PRs is lost. So we must draw a line.

I'm sorry if this sounds harsh, but I'm writing this for everyone's posterity, as I've seen the wider communities on GitHub also reject PRs that have a high amount of AI code. I agree with the sentiment and I want to be transparent about it.