Topics subtopics are not respected without a name

[amphro]

Repo:
Given the following topics list in the oclif package.json:

"topics": {
      "t1": {
        "description": "desc for t1",
        "subtopics": {
          "t1-1": {
            "description": "desc for t1-1",
            "subtopics": {
              "t1-1-1": {
                "description": "desc for t1-1-1"
              },
              "t1-1-2": {
                "description": "desc for t1-1-2"
              }
            }
          }
        }
      }
    }
  },

Then run ./bin/run t1 --help.

Expected results:

USAGE
  $ bin t1:COMMAND

COMMANDS
  t1:t1-1  desc for t1-1

Actual results:

USAGE
  $ bin t1:COMMAND

COMMANDS
  t1:t1-1  desc for the first command in t1-1

Potential Fix
I debugged this a little big and narrowed it down to this line: https://github.com/oclif/config/blob/master/src/plugin.ts#L249

Specifically ${base}${input[k].name}. It seems like what you want here is actually ``${base}${k}` since you are still dealing with the object, but not sure the original intent. The code looks like it wants a name property in the subtopic property but that seems counter-intuitive since I'm using a map. If I make the change locally, everything works fine, but I'm not sure if I am breaking another case.

If I have time, I'll try to create a PR.

[jdx]

yeah this is a little odd. For a little background that explains why this is like this: I went back and forth about whether or not there should be a 'name' field. I never wanted the name field in the configuration, my intention was for that to be populated inside the code with the key of the object it was inside of. It makes it a little easier to pass around a complete topic object that has the name attached. See in places like this: https://github.com/oclif/plugin-help/blob/master/src/index.ts#L48

So I think we do need the name. I'm not sure where it's populating that field exactly though, I would expect it to be in this repo but I can't seem to find it.

[amphro]

Also worth noting, I can't get other variations to work. Like

    "topics": [{
      "name": "t1",
      "description": "desc for t1",
      "subtopics": [{
        "name": "t1-1",
        "description": "desc for t1-1",
        "subtopics": [{
          "name": "t1-1-1",
          "description": "desc for t1-1-1"
        }, {
          "name": "t1-1-2",
          "description": "desc for t1-1-2"
        }]
      }]
    }]

Do you have a working example for nested topics?

[jdx]

You're mixing up how we reference topics in the code vs how they should be referenced in the config, they're not the same. In the code, we deal with a single array of all the topics including all subtopics but in the config it's a nested object. It's strange, but I've found this is the easiest way to deal with them in both places.

[jdx]

Having said that, we don't do much work with deeply nested things so I wouldn't be surprised if there was a bug inside of this logic. Let me see if I can work up an example.

[amphro]

Alright, you are right with adding names. This works:

    "topics": {
      "t1": {
        "name": "t1",
        "description": "desc for t1",
        "subtopics": {
          "t1-1": {
            "name": "t1-1",
            "description": "desc for t1-1",
            "subtopics": {
              "t1-1-1": {
                "name": "t1-1-1",
                "description": "desc for t1-1-1"
              },
              "t1-1-2": {
                "name": "t1-1-2",
                "description": "desc for t1-1-2"
              }
            }
          }
        }
      }
    }

Still seems odd to me that I need to duplicate the name when the framework can easily fo that for me. Also, I'm still not sure why my previous example didn't work, because it has a name and you have code in there to handle arrays.

[jdx]

This is incorrect behavior as to how it should work, I was just explaining why it's like this. How you imagined it is how it should work. I'm going to take a closer look.

[oclif-bot]

🎉 This issue has been resolved in version 1.7.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀