Merge-MarkdownHelp expectation when parameter type varies across versions?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 28/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- markdown, powershell
- Área
- documentation, tooling
Línea de trabajo
Comience con el archivo platyPSIssue3.zip proporcionado y reproduzca Merge-MarkdownHelp usando los cuatro directorios de Exchange Server y los archivos New-MailboxImportRequest.md. Inspeccione la salida combinada para comprobar el parámetro Mailbox y la sección SYNTAX; el trabajo estará terminado cuando exista un resultado documentado y coherente para los distintos valores de Type, conjuntos de parámetros y valores de Applicable entre versiones.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I wouldn't necessarily call this a bug, but what is the expected Merge-MarkdownHelp result if the Type value of the same parameter in the same cmdlet changes from one version of the product to another (e.g., Exchange 2013 to Exchange 2016)?
For example, the Mailbox parameter in the New-MailboxImportRequest cmdlet. In Exchange 2010 and Exchange 2013, the Type value is MailboxOrMailUserIdParameter. In Exchange 2016 and Exchange 2019, the Type value is MailboxLocationIdParameter. The actual description portions of the parameter is the same across versions.
If you create the following folder structure with the appropriate files:
\Exchange Server 2010\New-MailboxImportRequest.md
\Exchange Server 2013\New-MailboxImportRequest.md
\Exchange Server 2016\New-MailboxImportRequest.md
\Exchange Server 2019\New-MailboxImportRequest.md
And then run the following commands:
$x = "<path>\Exchange Server 2010","<path>\Exchange Server 2013","<path>\Exchange Server 2016","<path>\Exchange Server 2019"
Merge-MarkdownHelp -Path $x -OutputPath "<path>\platyPSissue\Merged" -ExplicitApplicableIfAll
You'll see in the resulting attached output file, the Type value of the Mailbox parameter is MailboxOrMailUserIdParameter only (the 2010/2013 values). Shouldn't the Mailbox parameter contain multiple YAML sections like this?
Type: MailboxOrMailUserIdParameter
Parameter Sets: (All)
Aliases:
Applicable: Exchange Server 2010, Exchange Server 2013
Required: True
Position: 1
Default value: None
Accept pipeline input: True (ByPropertyName, ByValue)
Accept wildcard characters: False
Type: MailboxLocationIdParameter
Parameter Sets: (All)
Aliases:
Applicable: Exchange Server 2016, Exchange Server 2019
Required: True
Position: 1
Default value: None
Accept pipeline input: True (ByPropertyName, ByValue)
Accept wildcard characters: False
And what about parameter sets in the SYNTAX section? As you can see, the Mailbox parameter only has the MailboxOrMailUserId parameter:
## SYNTAX
New-MailboxImportRequest [-Mailbox] <MailboxOrMailUserIdParameter> ...
Shouldn't there be two parameter sets? And what to call them and/or how to duplicate and tack and identifier on the end of the parameter set name like this?
## SYNTAX
### MailboxOrMailUserId
New-MailboxImportRequest [-Mailbox] <MailboxOrMailUserIdParameter> ...
### MailboxLocationId
New-MailboxImportRequest [-Mailbox] <MailboxLocationIdParameter> ...
And of course, this would change the Applicable values in the YAML sections in the parameter description.
Is this known or expected behavior?
- Lenguaje dominante
- C#
- Estrellas
- 870
- Forks
- 166
- Merge medio
- 21 h 17 min
- PR fusionados (30 d)
- 1
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de PowerShell/platyPS
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
PowerShell/platyPS#857 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 62/100
PowerShell/platyPS#863 ·
-
Export-MamlCommandHelp: a module file in the batch aborts the whole export and writes nothingAbierto
Dificultad 3/5 1-2 días Aptitud para principiantes 72/100
PowerShell/platyPS#862 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
PowerShell/platyPS#861 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 64/100
PowerShell/platyPS#860 · 1 comentario ·
Todos los issues de PowerShell/platyPS
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
question
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
代理地址输入框的示例提示容易被误认为已配置代理Posiblemente ocupada @jay23606 la tomó hoy. Abiertobug
Dificultad 1/5 1-3 horas Aptitud para principiantes 78/100
kookxiang/jellyfin-plugin-bangumi#297 ·
Los mantenedores suelen responder en 1 día
-
A numeric literal is parsed in the host's culture, so 1.5 is 15 in a made EXE on a comma-decimal OSAbiertobug interpreter silently-wrong small
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día