SystemLinkShared `editGridIconHtml` property is not redered in development

[gergo-papp]

🐛 Bug Report

💻 Repro or Code Sample

Thi sis how the edit grid icon is currently built:

import { DesignSystem } from '@microsoft/fast-foundation';
import { IconThreeVerticalLines } from '@ni/nimble-components/dist/esm/icons/three-vertical-lines';

export class SLGridColumns {
    public static readonly editGridIconHtml = `<${DesignSystem.tagFor(IconThreeVerticalLines)}></${DesignSystem.tagFor(IconThreeVerticalLines)}>`;
}

Then this gets evaluated in development, while running with a linked configuration, the DesignSystem.tagFor(IconThreeVerticalLines) evaluates to undefined

🤔 Expected Behavior

It should work in dev

😯 Current Behavior

SLGridColumns.editGridIconHtml === undefined;

💁 Possible Solution

As a quick fix, we can hardcode the tag

🔦 Context

🌍 Your Environment

• OS & Device: [e.g. MacOS, iOS, Windows, Linux] on [iPhone 7, PC]
• Browser [e.g. Microsoft Edge, Google Chrome, Apple Safari, Mozilla FireFox]
• Version [e.g. 1.8.0]

[jattasNI]

@mollykreis could you take a look at this as part of your SLE grid refactoring?

One thing to try would be to use iconThreeVerticalLinesTag instead of DesignSystem.tagFor(). This is the long term preferred approach but we haven't gotten to #1094 yet to do this holistically.

[rajsite]

One thing to try would be to use iconThreeVerticalLinesTag instead of DesignSystem.tagFor(). This is the long term preferred approach but we haven't gotten to #1094 yet to do this holistically.

Which you can see that the <iconName>Tag export is created by invoking DesignSystem.tagFor. So I would be surprised if that resolved to different things as the underlying implementation is the same,

Then this gets evaluated in development, while running with a linked configuration, the DesignSystem.tagFor(IconThreeVerticalLines) evaluates to undefined

@gergo-papp the behavior you see is only in development configuration not production right? Can you give more details of the development configuration you are using?

I tried to reproduce the issue using an angular dev config build in the example app but did not run into the same behavior.

[rajsite]

Root cause was a multi-workspace repository attempting to link multiple workspaces together using tsconfig paths resulting in resolved import paths for the same identifier unpredictably pulling from node_modules folders in different workspaces.

This resulted in the import of fast-foundation resolving to multiple modules each creating registries resulting in multiple instances of what should be singleton objects. The specific approach used for linking across workspaces is not valid for modules relying on standard npm node module resolution such as nimble.

Discussion to improve the behavior of the multi-workspace repo is in Skyline.