Ansible filter fails when parsers have a dash in their names?

I realise I should probably be asking this in community.general…

Does the community.general.jc ansible filter simply fail for parsers with a dash in their names?

---
- name: JC test
  block:

    - name: List files in /tmp using ls -1l /tmp
      ansible.builtin.command: ls -1l /tmp
      check_mode: false
      changed_when: false
      register: jc_ls_1l

    - name: Set a fact for the result of ls -1l /tmp
      ansible.builtin.set_fact:
        jc_ls: "{{ jc_ls_1l.stdout | community.general.jc('ls') }}"

    - name: Debug list files in /tmp
      ansible.builtin.debug:
        var: jc_ls

    - name: List packages using dpkg -l
      ansible.builtin.command: dpkg -l
      environment:
        COLUMNS: 500
      check_mode: false
      changed_when: false
      register: jc_dpkg_l

    - name: Set a fact for the result of dpkg -l
      ansible.builtin.set_fact:
        jc_dpkg: "{{ jc_dpkg_l.stdout | community.general.jc('dpkg-l') }}"

  tags:
    - jc
...

Results in:

TASK [jc : List files in /tmp using ls -1l /tmp] *******************************
ok: [localhost]
TASK [jc : Set a fact for the result of ls -1l /tmp] ***************************
ok: [localhost]
TASK [jc : Debug list files in /tmp] *******************************************
ok: [localhost] => {
    "jc_ls": [
        {
            "date": "Nov 7 22:07",
            "filename": "ansible_ansible.legacy.command_payload_sn843j60",
            "flags": "drwx------",
            "group": "root",
            "links": 2,
            "owner": "root",
            "size": 4096
        }
    ]
}
TASK [jc : List packages using dpkg -l] ****************************************
ok: [localhost]
TASK [jc : Set a fact for the result of dpkg -l] *******************************
fatal: [localhost]: FAILED! => {"msg": "Error in jc filter plugin:  No module named 'jc.parsers.dpkg-l'"}

Or am I doing something daft?

[chriscroome]

Good plan, I’ll leave that to you 😉 .

[kellyjonbrazil]

Yeah it probably makes sense to update the parser parameter comments on that documentation page. I think we can just submit a PR with the updated verbiage and it will go into the next release.