Hi team - thank you for sharing great config. I'm loving it!

I found that the current WindowsDeveloperConfig DSC setup can overwrite an existing custom oh-my-posh initialization line in my PowerShell profile.

First, I want to say I totally understand this project is intentionally opinionated, so using the default oh-my-posh setup is completely reasonable if that is the intended behavior. I’m opening this mostly because it was confusing to me at first that DSC was modifying only the oh-my-posh line in my PowerShell profile silently changing prompt, and I wanted to leave a note in case someone else runs into the same thing.

I also fully admit my suggested workaround may be a bit over-engineered and potentially inefficient: using a separate script-based DSC resource to detect an existing oh-my-posh line, even though there is already a dedicated OhMyPosh/Shell DSC implementation, is not ideal on paper. However, based on the current behavior on both sides, it seems like this may be the only practical way to avoid overwriting an existing custom oh-my-posh setup.

Current behavior

In windows-dev-config/dev-config.winget, the config uses:

- type: OhMyPosh/Shell
  name: ohMyPoshProfileSet
  dependsOn:
    - OhMyPosh
  properties:
    states:
      - name: pwsh
        command: oh-my-posh init pwsh

When DSC is applied, it updates the existing oh-my-posh init line in $PROFILE to the declared command.

That means a custom line like:

oh-my-posh init pwsh --config "$HOME\.config\oh-my-posh\M365Princess.omp.json" | Invoke-Expression

gets rewritten to:

oh-my-posh init pwsh | Invoke-Expression

Why this is a problem

Many users customize their prompt via --config, and this is valid/manual user configuration. The rest of the profile remains untouched, but the oh-my-posh line is normalized and the custom theme/config is lost.

Suggested change

Instead of using OhMyPosh/Shell directly here, please consider using a script-based DSC resource that:

• checks whether $PROFILE already contains any non-comment oh-my-posh init line
• skips modification if one already exists
• only appends the default oh-my-posh init pwsh | Invoke-Expression line when no existing oh-my-posh initialization is present

This would preserve existing user customization while still bootstrapping oh-my-posh for users who do not already have it configured.

Why I’m suggesting this on the WindowsDeveloperConfig side

The upstream oh-my-posh DSC resource currently rewrites the matched init line unless it already contains the exact canonical command string, so it does not preserve extra args like --config. I totally admit that writing separate script to check oh-my-posh init line is bit over-engineered and potentially inefficient.

Possible implementation direction

A Microsoft.DSC.Transitional/PowerShellScript resource could use:

• testScript: return $true if $PROFILE already contains a non-comment oh-my-posh init line
• setScript: create $PROFILE if missing and append the default line only if no such line exists

Expected behavior

If the profile already contains any valid oh-my-posh init command, DSC should treat that as compliant and avoid modifying it.