Bump flex-fields to 10.0.0-rc.16, drop Site's own Matrix/Table - #62
Merged
Conversation
Bumps @dignite/ng.flex-fields, its -ckeditor/-file-explorer adapters and @dignite/ng.file-explorer from ^10.0.0-rc.15 to ^10.0.0-rc.16. Unlike every previous bump, rc.16 was published in abp-modules only via workflow_dispatch (no tag), so it landed on GitHub Packages under the @dignite-projects org scope only - the tag-triggered step that mirrors to public npmjs under the real @dignite scope never ran. angular/package.json's four entries now alias to npm:@dignite-projects/<name>@<range> to reach it; angular/projects/site/ package.json keeps the plain public names, since that's what a real downstream consumer needs. check-angular-package-duplicates.mjs's target list moved from @dignite to @dignite-projects to match (it matches on installed manifest name, and every alias now on disk carries the real @dignite-projects identity). ci.yml gained packages: read; both workflows' "Manage Actions access" explanation is consolidated into release.yml's one canonical copy. This also fixed a release-blocking gap the bump exposed: release.yml's "Verify packed npm package installs and bundles cleanly" (packed mode) installs the *raw* packed manifest, which still names its siblings by their plain public names - the alias rewrite only happens later, at the GitHub Packages publish step - and the release's NuGet packages are already pushed live by the time that step runs. verify-packed-npm-install.sh's packed mode now takes an optional github-token argument and points every @dignite/* range the tarball declares (read fresh, not hardcoded) at its @dignite-projects alias via npm overrides. Verified against a real packed tarball: fails with the original ETARGET error without the token, installs and bundles cleanly with it. Removes Site's own Matrix and Table field types, superseded by flex-fields' kernel built-ins of the same name shipped in rc.16. abp-modules ported both verbatim - registration keys, configuration keys and camelCase value shapes unchanged - so this is a pure deletion with no data migration. Also deletes Dignite.FlexFields.Site's own ICompositeFieldType/INormalizesValue/ InlineFieldDefinition/InlineFieldValidator/CompositeFieldNesting, ported byte-for-byte identical into the kernel; every file that referenced Site's copies already carried a `using Dignite.Abp.FlexFields;` alongside `using Dignite.FlexFields.Site;`, so this compiled with no code changes there - just fully-qualified the three remaining references afterward (FieldManager, ContentManager, FieldAdminAppService) so a future same-named Site-local type fails loudly instead of being silently shadowed, and dropped the two files' now-dead `using Dignite.FlexFields.Site;`. This was not optional: dotnet build against abp-modules' current main (which this workspace path-references) failed with three CS0104 ambiguous-reference errors the moment both copies existed side by side. Two new FieldAdminAppService_Tests cases close the resulting coverage gap - ci.yml deliberately never runs abp-modules' own tests, so without them a regression in the kernel's ported Matrix/Table would get no CI signal here at all. They prove Site's own integration points (the Composite flag, the nesting-depth check) still reach the kernel's types correctly, without re-testing the kernel's own Normalize/Validate internals. Verified: dotnet build (0 errors), every dotnet test project that ran before this change still passes after it (252/317/15/12 across Domain/ EntityFrameworkCore/HttpApi.Client/Mcp), yarn build:site, yarn build (Host), yarn ng test site (29 tests), and both check-angular-package-* scripts. Manual follow-up still needed outside this repo: grant dignite-projects/site "Manage Actions access" to abp-modules' four flex-fields packages (UI-only, no API) so ci.yml's own GITHUB_TOKEN can read them.
…_TOKEN The previous commit's fix assumed granting dignite-projects/site "Manage Actions access" on abp-modules' four flex-fields packages would let this repo's own GITHUB_TOKEN read them. It doesn't: a live CI run against this branch 401'd on "Install Angular dependencies" with that grant already in place. GITHUB_TOKEN's package read access is scoped to the workflow's own repository, full stop - there's no cross-repo extension for "Manage Actions access" to unlock. release.yml's NuGet side already knew this and worked around it with PACKAGES_READ_TOKEN, a PAT scoped to read:packages, per that step's own pre-existing comment. Applies the same fix to the npm side: angular/.npmrc, both verify-packed-npm-install.sh invocations (packed and published - the latter needed this too, just never exercised against a GitHub-Packages-only flex-fields version before now), and ci.yml's job-level env now all use PACKAGES_READ_TOKEN instead. ci.yml's now-unnecessary packages: read permission is removed. Verified against a real packed tarball and a real yarn install, both with a personal read:packages-scoped token standing in for the secret.
…token The real cause of the two 401s on "Install Angular dependencies", which neither of the previous two attempts hit: Yarn Classic picks the registry - and therefore the auth token - for a tarball download by the scope of the name it knows the package by. angular/package.json aliases these as "@dignite/ng.flex-fields": "npm:@dignite-projects/ng.flex-fields@<range>", so that name is @dignite/..., and only @dignite-projects was mapped in angular/.npmrc. Yarn fell back to the default registry, saw the tarball's host didn't match it, sent no credential, and GitHub answered 401. It only reproduces on a cold yarn cache - a warm cache never downloads the tarball and never reaches that code path - which is why every local yarn install passed while CI failed twice. Reproduced locally by pointing YARN_CACHE_FOLDER at an empty directory, with a token that demonstrably can read these packages, and confirmed fixed the same way: cold cache, --frozen-lockfile, all four packages installed at 10.0.0-rc.16. Also corrects what the previous commit asserted. The 401s were never evidence about GITHUB_TOKEN's cross-repo reach - yarn was sending no token at all, so that question was never actually put. PACKAGES_READ_TOKEN stays, now on the honest grounds it always had: GITHUB_TOKEN's package access is documented as scoped to the workflow's own repository, and the NuGet side of release.yml already made the same call for the same reason. Whether the ephemeral token would also work now is untested and one commit away for anyone who wants it. No "Manage Actions access" grant is needed either.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
@dignite/ng.flex-fields(+-ckeditor/-file-exploreradapters,@dignite/ng.file-explorer) from^10.0.0-rc.15to^10.0.0-rc.16. That version was published in abp-modules only viaworkflow_dispatch, so it's currently GitHub-Packages-only (not on public npmjs) -angular/package.jsonaliases the four packages to their@dignite-projectsGitHub Packages identity to reach it.Matrix/Tablefield types (C# + Angular), now superseded by identical built-ins flex-fields ships in rc.16 (verbatim port - registration/config keys and value shapes unchanged, no data migration). Also removes the shared composite-field contracts (ICompositeFieldType,INormalizesValue, etc.) Site had defined locally, since the kernel now ships byte-identical copies and every consuming file already had the rightusingin place; the three remaining references are now fully-qualified so a future same-named local type fails loudly rather than silently shadowing.release.yml's packed-npm-install verify step would have 404'd on the next real release, after NuGet packages were already pushed live.verify-packed-npm-install.sh'spackedmode now takes a token and applies the same alias vianpm overrides, read fresh from the tarball (not hardcoded).The CI failure this branch worked through
Two runs 401'd on "Install Angular dependencies" before the cause was actually pinned down, and the first two explanations were wrong (a missing "Manage Actions access" grant; then
GITHUB_TOKEN's cross-repo scoping). Neither was it.Yarn Classic picks the registry - and therefore the auth token - for a tarball download by the scope of the name it knows the package by. With
npm:aliases that is the alias's scope (@dignite), not the target's (@dignite-projects), and only the latter was mapped inangular/.npmrc. Yarn fell back to the default registry, saw the tarball's host didn't match, sent no credential at all, and GitHub answered 401. It reproduces only on a cold yarn cache - which is why every local install passed - and was confirmed both ways locally withYARN_CACHE_FOLDERpointed at an empty directory before being pushed. The fix is one line: map@digniteto GitHub Packages too.npm auth also moved from
secrets.GITHUB_TOKENto the existingPACKAGES_READ_TOKENsecret along the way, matching whatrelease.yml's NuGet verification already did. That rides onGITHUB_TOKEN's documented "own repository only" package scoping, not on the 401s - yarn was sending no token at all, so that question was never actually put. No "Manage Actions access" grant is required.Test plan
dotnet build- 0 errorsdotnet test- Domain (252), EntityFrameworkCore (317), Public.HttpApi.Client (15), Mcp (12)yarn build:site,yarn build(Host),yarn ng test site(29 tests)check-angular-package-duplicates.mjs/check-angular-package-deps.mjsverify-packed-npm-install.sh packedagainst a real tarball, with and without a tokenyarn install --frozen-lockfilereproduced the 401 and confirmed the fix