systemlink-cli 1.13.7__tar.gz → 1.13.8__tar.gz

{systemlink_cli-1.13.7 → systemlink_cli-1.13.8}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: systemlink-cli
-Version: 1.13.7
+Version: 1.13.8
 Summary: SystemLink Integrator CLI - cross-platform CLI for SystemLink workflows and templates.
 License-File: LICENSE
 Author: Fred Visser

{systemlink_cli-1.13.7 → systemlink_cli-1.13.8}/pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "systemlink-cli"
-version = "1.13.7"
+version = "1.13.8"
 description = "SystemLink Integrator CLI - cross-platform CLI for SystemLink workflows and templates."
 authors = ["Fred Visser <fred.visser@emerson.com>"]
 packages = [{ include = "slcli" }]

{systemlink_cli-1.13.7 → systemlink_cli-1.13.8}/slcli/_version.py

@@ -1,4 +1,4 @@
 """Version information for slcli."""
 
 # This file is auto-generated. Do not edit manually.
-__version__ = "1.13.7"
+__version__ = "1.13.8"

{systemlink_cli-1.13.7 → systemlink_cli-1.13.8}/slcli/skills/systemlink-webapp/SKILL.md

@@ -38,7 +38,7 @@ Before generating code, clarify only the details that change the implementation:
 4. Auth context: same-origin hosted app versus remote/dev API-key flow.
 5. Deployment target: ordinary hosted webapp only, or Plugin Manager package as well.
 
-Do not ask about Angular or Nimble versions unless the user is constrained by an existing project. Default to Angular 20 and the latest compatible `@ni/nimble-angular`.
+Do not ask about Angular or Nimble versions unless the user is constrained by an existing project. Default to Angular 20 and the latest compatible `@ni/nimble-angular`, but verify the installed versions immediately after scaffold instead of assuming the generator produced the expected combination.
 
 For new SystemLink apps, recommend installing the NI Angular UI packages together unless the user is intentionally minimizing dependencies. `@ni/nimble-angular` remains the default foundation, `@ni/spright-angular` adds Spright chat and icon components, and `@ni/ok-angular` adds OK-specific controls such as accordion items and search input.
 
@@ -56,11 +56,31 @@ Then generate Angular in that starter directory so the SystemLink scaffolding st
 
 ```bash
 npx -y @angular/cli@20 new <app-name> --directory . --routing --style=scss --skip-git --no-standalone --defaults --force
-npm install @ni/nimble-angular @ni/spright-angular @ni/ok-angular @ni/systemlink-clients-ts
+npm install @ni/nimble-angular @ni/nimble-components @ni/unit-format @ni/spright-angular @ni/ok-angular @ni/systemlink-clients-ts @angular/localize
+npm install --save-dev @angular-devkit/build-angular
 ```
 
 Prefer NgModule-based apps for this workflow. The Nimble Angular wrapper modules fit naturally into a centralized `AppModule`, which reduces template surprises and keeps imports explicit.
 
+Immediately after scaffold, inspect `package.json` and `angular.json` before building features. The generator or migrations may leave the workspace on the wrong Angular major or on a builder configuration that does not bundle `@ni/nimble-angular` cleanly.
+
+For the currently supported path, standardize on:
+
+- Angular 20.x
+- `@ni/nimble-angular` 33.2.x
+- `@ni/nimble-components` 35.8.x
+- `@ni/unit-format` 1.0.4+
+- `@angular/localize` installed and added to build and test polyfills
+
+If the workspace ends up on `@angular/build:application` and Nimble fails to bundle with `Could not resolve '@ni/nimble-components/dist/esm/...'`, switch `angular.json` back to the legacy Angular builders:
+
+- `@angular-devkit/build-angular:browser`
+- `@angular-devkit/build-angular:dev-server`
+- `@angular-devkit/build-angular:extract-i18n`
+- `@angular-devkit/build-angular:karma`
+
+This fallback is not optional when the Nimble packages fail under the application builder. Fix the builder mismatch before implementing more UI.
+
 Recommend installing `@ni/spright-angular` and `@ni/ok-angular` early even if the first slice only uses Nimble. That avoids dependency churn later when the UI needs chat surfaces, product-specific icons, accordion items, or the OK search input.
 
 If the user has not run `slcli webapp init` and explicitly wants a SystemLink-hosted webapp, recommend it first unless they want a manual setup.
@@ -76,6 +96,8 @@ These decisions prevent the most common hosted-webapp failures:
 - Do not add `CUSTOM_ELEMENTS_SCHEMA` just to silence missing Nimble module imports.
 - Put theme-aware color and shadow aliases on `nimble-theme-provider`, not on `:root`.
 - Import `@angular/localize/init` in Angular polyfills for both build and test paths.
+- Import Nimble fonts once in the root `src/styles.scss` with `@use '@ni/nimble-angular/styles/fonts' as *;`. Without this, Nimble components render with fallback system fonts instead of the required Source Sans Pro typeface.
+- Run a production build immediately after setup changes. Do not postpone the first `npm run build` until after the UI is implemented.
 
 If you need the exact module patterns or template wiring, load [references/nimble-angular.md](./references/nimble-angular.md).
 If you need a concise package-level inventory before choosing components, load [references/angular-ui-packages.md](./references/angular-ui-packages.md).
@@ -90,6 +112,16 @@ Use SystemLink-appropriate layout defaults instead of inventing page structure f
 - Use accordions for grouped fields and advanced configuration.
 - Use cards sparingly for summaries, not as the default editing or data layout.
 
+Treat Nimble alignment as a requirement, not a style preference:
+
+- Use Nimble controls for primary actions, selection, inputs, status, and data display.
+- Use raw HTML elements mostly for semantic grouping, layout wrappers, and text structure.
+- Do not build custom-styled buttons, inputs, dropdowns, tabs, or pseudo-cards when Nimble already provides the interaction primitive.
+- Prefer Nimble spacing, borders, focus states, and theme tokens over bespoke visual treatments.
+- If a page starts to look like a generic marketing dashboard instead of a SystemLink tool, pull it back toward table/list-detail, drawers, banners, tabs, and structured metadata panels.
+
+The goal is a webapp that feels native to the SystemLink shell, not an arbitrary Angular site hosted inside it.
+
 Load [references/layout-patterns.md](./references/layout-patterns.md) when the task turns into page composition, spacing, or shell layout work.
 
 ### 4. Integrate SystemLink APIs the low-risk way
@@ -117,6 +149,14 @@ When the user asks for implementation, prefer one working slice over a full app
 - one error banner
 - one settings/control path only if required
 
+For a new app, the first vertical slice should also prove the setup:
+
+- scaffold completes
+- Angular and NI package versions are compatible
+- the app builds successfully
+- one Nimble-based route renders
+- one real SystemLink query works in the hosted shell
+
 This keeps context narrow and usually reveals the real integration blockers faster than broad scaffolding.
 
 ### 6. Publish or package only after the hosted constraints are covered
@@ -137,6 +177,7 @@ Always verify:
 - the browser console is clear of blocking errors
 - the correct SystemLink data loads
 - light/dark theme switching updates the app in real time
+- the page still reads as a Nimble/SystemLink experience rather than a custom HTML dashboard
 
 Load [references/troubleshooting.md](./references/troubleshooting.md) for the hosted validation flow and symptom-based fixes.
 
@@ -145,14 +186,20 @@ Load [references/troubleshooting.md](./references/troubleshooting.md) for the ho
 Before you consider a SystemLink webapp slice correct, confirm all of the following:
 
 - Angular 20 workspace created in the intended starter directory.
+- Angular and NI package versions verified after scaffold, not assumed.
+- `@ni/nimble-components`, `@ni/unit-format`, `@angular/localize`, and `@angular-devkit/build-angular` installed when using `@ni/nimble-angular`.
+- `angular.json` uses builders that are known to bundle Nimble successfully.
 - `AppModule` provides `APP_BASE_HREF`.
 - `index.html` does not contain a `<base>` element.
 - Router uses `useHash: true`.
 - Production build disables `inlineCritical`.
+- Root `src/styles.scss` imports `@use '@ni/nimble-angular/styles/fonts' as *;`.
 - Nimble Angular modules are imported explicitly.
+- Primary interaction controls use Nimble wrappers rather than custom HTML surrogates.
 - No hardcoded colors in component SCSS.
 - Theme-aware aliases live on `nimble-theme-provider`.
 - API client uses the correct SystemLink service base URL.
+- `npm run build` passes before publish.
 - Hosted deployment is validated after publish.
 
 ## Default implementation stance
@@ -162,20 +209,26 @@ Use these defaults unless the user asks for a different tradeoff:
 - Angular 20
 - NgModule-based app
 - `@ni/nimble-angular`
+- `@ni/nimble-components`
+- `@ni/unit-format`
 - `@ni/spright-angular`
 - `@ni/ok-angular`
 - `@ni/systemlink-clients-ts`
 - table-first data presentation
 - same-origin cookie auth
 - long-form CLI flags in examples and commands
+- Nimble-first interaction design with minimal bespoke chrome
 
 ## Common mistakes to prevent up front
 
 - Treating the app like a normal root-hosted Angular SPA instead of an iframe/sub-path app.
+- Assuming the scaffolded Angular major or builder is already correct for Nimble.
+- Waiting until the end of implementation to run the first production build.
 - Checking only the `theme` attribute instead of verifying resolved Nimble tokens.
 - Putting theme-aware aliases on `:root`.
 - Overriding SDK base URLs with incomplete service prefixes.
 - Using raw HTML controls where Nimble primitives should define the interaction model.
+- Letting the page drift into a custom dashboard aesthetic that ignores Nimble interaction and spacing patterns.
 - Loading too much reference material before the task requires it.
 
 ## When to escalate into the references

{systemlink_cli-1.13.7 → systemlink_cli-1.13.8}/slcli/skills/systemlink-webapp/references/deployment.md

@@ -3,7 +3,10 @@
 ## Prerequisites
 
 - `slcli` installed and authenticated (`slcli login` or config file present)
-- Angular app built to `dist/<app-name>/browser/`
+- Angular app built successfully
+- Publish path confirmed for the active builder:
+  - `dist/<app-name>/browser/` for the application builder
+  - `dist/<app-name>/` for the legacy browser builder
 
 ---
 
@@ -11,12 +14,19 @@
 
 ```bash
 # Run from project root
-node_modules/.bin/ng build --configuration production --output-path dist/<app-name>
+node_modules/.bin/ng build --configuration production
 ```
 
 **Do NOT pass `--base-href`.** This would reintroduce a `<base>` element that violates SystemLink's CSP.
 
-Angular 19 places the browser output at `dist/<app-name>/browser/` — publish that subdirectory, not the parent.
+Angular may emit different publish roots depending on the active builder.
+
+- `@angular/build:application` emits browser assets under `dist/<app-name>/browser/`
+- `@angular-devkit/build-angular:browser` emits browser assets directly under `dist/<app-name>/`
+
+Always inspect the actual build output before publishing. Do not hardcode `/browser/` if the workspace is on the legacy builder.
+
+If `npm run build` fails with `Could not resolve '@ni/nimble-components/dist/esm/...'` while using `@ni/nimble-angular`, switch the workspace to the legacy Angular browser builder before continuing. Do not publish from a half-fixed setup.
 
 ### Background build (if terminal has heredoc/interrupt issues)
 
@@ -33,7 +43,7 @@ tail -f /tmp/ng-build.log
 ## First deploy (no existing webapp)
 
 ```bash
-slcli webapp publish dist/<app-name>/browser/ --workspace <workspace-name>
+slcli webapp publish <ACTUAL_BUILD_OUTPUT_DIR> --workspace <workspace-name>
 ```
 
 The command prints the new webapp ID. **Save it** — you need it for every future redeploy and for `slcli webapp open`.
@@ -49,7 +59,7 @@ Created webapp: 3727d9ac-86e1-4d6e-820e-d2630c1b28e9
 ## Redeploy (update existing webapp)
 
 ```bash
-slcli webapp publish dist/<app-name>/browser/ --workspace <workspace-name> --id <webapp-id>
+slcli webapp publish <ACTUAL_BUILD_OUTPUT_DIR> --workspace <workspace-name> --id <webapp-id>
 ```
 
 ---
@@ -86,9 +96,11 @@ Before publishing, verify:
 - [ ] `app.module.ts` provides `{ provide: APP_BASE_HREF, useValue: '/' }`
 - [ ] `app-routing.module.ts` uses `useHash: true`
 - [ ] `angular.json` has `inlineCritical: false` in production optimization
+- [ ] `angular.json` uses a builder that bundles `@ni/nimble-angular` successfully
 - [ ] `basePath` is `window.location.origin + '/<service-prefix>'` (not just origin)
 - [ ] `credentials: 'include'` (or equivalent) set on API client
 - [ ] Build succeeded with no errors (warnings about bundle size are OK if within 2MB error limit)
+- [ ] Publish path matches the active builder output
 
 ---
 
@@ -114,6 +126,11 @@ Before publishing, verify:
 - Beasties CSS inliner is injecting `onload` handlers
 - Fix: set `inlineCritical: false` in angular.json
 
+### Nimble packages fail to resolve during build
+
+- You may be on `@angular/build:application` with a Nimble package layout that esbuild does not resolve cleanly
+- Fix: install `@angular-devkit/build-angular` and switch to the legacy browser/dev-server builders in `angular.json`
+
 ### "Budget exceeded" build error
 
 Increase error limits in `angular.json`:

{systemlink_cli-1.13.7 → systemlink_cli-1.13.8}/slcli/skills/systemlink-webapp/references/nimble-angular.md

@@ -10,6 +10,32 @@ When building Angular apps with Nimble, use `@ni/nimble-angular` wrapper modules
 - Do not add `CUSTOM_ELEMENTS_SCHEMA` just to silence unknown Nimble elements in templates. That usually hides a missing module import and weakens Angular's template validation.
 - If a Nimble icon or control is unknown, first look for the matching module in `@ni/nimble-angular` and import it.
 
+## Fonts
+
+Nimble requires the Source Sans Pro font family. Without this import, all Nimble components render with fallback system fonts (Arial) and the UI will not match the SystemLink design system.
+
+Import the fonts **once** in the root `src/styles.scss`:
+
+```scss
+@use '@ni/nimble-angular/styles/fonts' as *;
+```
+
+This registers `@font-face` declarations for Source Sans Pro (Regular, Light, SemiBold) and Source Code Pro, loading `.woff2` files bundled in `@ni/nimble-tokens`.
+
+To use Nimble design tokens (colors, font sizes, spacing) in component SCSS files, also import:
+
+```scss
+@use '@ni/nimble-angular/styles/tokens' as *;
+
+.my-element {
+  font-family: $ni-nimble-body-font-family;
+  font-size: $ni-nimble-body-font-size;
+  color: $ni-nimble-body-font-color;
+}
+```
+
+Do not duplicate the fonts import in component SCSS — it belongs only in the global `styles.scss`.
+
 ## nimble-theme-provider
 
 Wrap your entire app. Always place at the root component level.

{systemlink_cli-1.13.7 → systemlink_cli-1.13.8}/slcli/skills/systemlink-webapp/references/troubleshooting.md

@@ -46,6 +46,7 @@ If the `theme` attribute changes but the colors do not:
 | Error or symptom                          | Likely cause                                          | Fix                                                                              |
 | ----------------------------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------- |
 | `$localize is not defined`                | Angular localize polyfill missing                     | Add `@angular/localize/init` to Angular polyfills                                |
+| `Could not resolve '@ni/nimble-components/dist/esm/...'` during build | Nimble package layout not bundling under Angular application builder | Install `@angular-devkit/build-angular` and switch `angular.json` back to the legacy browser/dev-server builders |
 | NG04002 or blank screen                   | Path routing under SystemLink sub-path                | Use hash routing                                                                 |
 | CSP `base-uri` error                      | `<base>` tag present                                  | Remove `<base>` and provide `APP_BASE_HREF` via DI                               |
 | CSP `unsafe-inline` error from styles     | Critical CSS inlining injected handlers               | Set `inlineCritical: false`                                                      |
@@ -63,6 +64,7 @@ If the `theme` attribute changes but the colors do not:
 - confirm `nimble-theme-provider` is present
 - confirm the required Nimble Angular modules are imported
 - confirm the app uses Nimble components instead of native HTML controls for primary interactions
+- confirm the page is not relying on custom-styled HTML buttons, inputs, or cards where Nimble controls should own the interaction
 
 ### App follows the shell theme attribute but colors still look wrong
 
@@ -76,6 +78,13 @@ If the `theme` attribute changes but the colors do not:
 - verify cookie auth versus API-key mode
 - verify the generated request body shape matches the real API
 
+### Build fails before the app ever runs
+
+- verify the Angular major matches the installed `@ni/nimble-angular` peer dependency
+- verify `@ni/nimble-components`, `@ni/unit-format`, and `@angular/localize` are installed
+- if the workspace uses `@angular/build:application` and Nimble imports fail to resolve, move back to `@angular-devkit/build-angular:browser`
+- rerun `npm run build` before changing more application code
+
 ### Dialogs or advanced overlays do not open
 
 - do not gate `nimble-dialog` with `*ngIf`
@@ -87,6 +96,7 @@ Before publishing or redeploying, verify:
 
 - no hardcoded colors remain in component styles
 - Nimble primitives are used for the main controls and data views
+- the page reads as a Nimble/SystemLink tool rather than a bespoke HTML dashboard
 - `APP_BASE_HREF` is provided and no `<base>` tag exists
 - routing uses `useHash: true`
 - production build disables `inlineCritical`