Replacing Lerna with pnpm on LTS #25537

jumyhre · 2025-09-24T18:23:04Z

This PR replaces lerna for client packages in the LTS branch with pnpm, and merges azure into the 'client' package group

The build tools version used by LTS isn't compatible with pnpm's workspace:~ dependency protocol, so we had to use a version of build-tools from main which does support that protocol. That introduced a few ancilliary changes we had to make:

1 - build-tools from main requires node>=20. As a result we've updated LTS to use node 20.15.1 (the min required version on main)

2 - Updating to node 20.15.1 required us to update our eslint dependency to a version compatible with node 20
2a - Updating eslint also introduced a number of linter changes to various code files

3 - the latest version of build-tools from main had similar but different type test generation code - we had to update the typeValidation JSON in various package.jsons, and the build-tools generated type tests are generated with slightly different names + paths

4 - we disabled the layer-checking policy check on LTS (per offline discussion, we decided it was unlikely there would be major dependency changes to LTS in the future, and so it would be a lot of work for little payoff to enable layer-checking using the latest build-tools version on LTS)

5 - Since main considers azure packages to be part of the client workgroup, we've added azure packages to this change and made them use pnpm
5a - This also lets us remove the build-azure pipeline, since azure gets included with the client packages build

6 - Several pipelines were updated to use pnpm, install pnpm dependencies, and use flub to publish packages. Where possible, the implementations have been pulled directly from main

7 - build-tools sources (and associated pipeline to build build-tools) have been removed. We're now using build-tools from main, which means this code is no longer needed to be built or maintained (NB: the server/ code which uses old build-tools is planned to be removed in a subsequent PR)

Workarounds needed:

api-extractor dependencies are using ~7.22.2 instead of ^7.22.2 now. This was to work around an issue with api-extractor, where ^ dependencies used an inconsistent version of the typescript compiler that caused build failures (and the command line switch to point api-extractor to the right compiler to use did not work)
eslint configurations have been set to use 0.28.2000. This resulted in a downgraded eslint config for some projects. This was done because of the migration to node 20 - eslint config 0.28.2000's dependencies were compatible with node 20, but 2.0.0 included extra dependencies which were incompatible with node 20
@types/node set to 14.18.0 everywhere - trying to use a different types/node version caused typescript compilation failures when processing d.ts files of those libraries, and options like skipLibCheck etc did not fix it. Setting all projects to @types/node 14.18.0 resolved the issue (NB: main has a similar workaround of using node types v 18 due to compilation issues, despite it using node 20+)

The build tools version used by LTS isn't compatible with pnpm's workspace:~ dependency protocol, so we had to use an version of build-tools from main which does support that protocol. That introduced a few ancilliary changes we had to make: 1 - build-tools from main requires node>=20. As a result we've updated LTS to use node 20.15.1 (the min required version on main) 2 - Updating to node 20.15.1 required us to update our eslint dependency to a version compatible with node 20 2a - this also introduced a number of linter fixes to various code files 3 - the latest version of build-tools from main had similar but different type test generation code - we had to update the typeValidation JSON in various package.jsons, and the build-tools generated type tests are generated with slightly different names + paths 4 - we disabled the layer-checking policy check on LTS (per offline discussion, we decided it was unlikely there would be major dependency changes to LTS in the future, and so it would be a lot of work for little payoff to enable layer-checking using the latest build-tools version on LTS) 5 - Since main considers azure packages to be part of the client workgroup, we've added azure packages to this change and made them use pnpm 5a - This also lets us remove the build-azure pipeline, since azure gets included with the client packages build 6 - Several pipelines were updated to use pnpm, install pnpm dependencies, and use flub to publish packages. Where possible, the implementations have been pulled directly from main

jumyhre · 2025-09-24T18:27:50Z

azure/packages/test/scenario-runner/package.json

 		"start:server": "node ./dist/server.js",
 		"test": "echo \"Error: no test specified\" && exit 1",
-		"test:realsvc": "npm run test:realsvc:tinylicious",
+		"test:realsvc": "echo Test disabled on LTS",


Note for reviewers: I disabled this because:

This actually wasn't running on existing azure pipeline runs (one example: https://dev.azure.com/fluidframework/internal/_build/results?buildId=254938&view=logs&j=3dc8fd7e-4368-5a92-293e-d53cefc8c4b3&t=8ee6b0c5-48a4-51bb-d1f6-a7ad1e52f3d2 )

The test steps weren't set up right - test:realsvc:tinylicious tries to invoke start:tinylicious:test, but that script doesn't actually exist, so it fails. I did some best effort work to enable this, but when I got the tests running I found there were too many failures for me to reasonably address in this PR and decided getting it working was out of scope

I think it's fine, scenario-runner is already gone in main and IIRC it had its own pipeline. One could argue maybe we should remove it here but disabling the tests seems fine to me.

jumyhre · 2025-09-24T18:35:00Z

packages/runtime/test-runtime-utils/src/assertionShortCodesMap.ts

@@ -8,693 +8,698 @@
 // Auto-generated by policy-check in @fluidframework/build-tools.

 export const shortCodeMap = {


Not sure if this addition is right - this is the result of running flub's assertion tagging tool on the repo. I'm surprised it added every assertion message in the repo here

I'd expect it, the infrastructure to generate this file during assert tagging came into being once LTS wasn't the active branch. However, as I mentioned in another comment, I'd vote for not running assert tagging if we can avoid it. Not the end of the world if we have to, though (and this file is purely a development-time helper so it's fine if it ends up here).

+1 to not running assert tagging. If people care about bundle size, they should bump to modern fluid versions. They can live with string error codes in the meantime if we need to add any asserts to LTS

jason-ha

I have been able to cover all root files and directories alphabetically through examples. Look good with some questions.

jason-ha · 2025-09-24T18:36:14Z

azure/packages/azure-local-service/package.json

 	"devDependencies": {
 		"@fluidframework/build-common": "^1.2.0",
-		"@fluidframework/eslint-config-fluid": "^2.0.0",
+		"@fluidframework/eslint-config-fluid": "^0.28.2000",


It was at 2.0+ and has to go down to 0.28.2000?
(here and other files too)

Yeah this is a bit weird - I made it because eslint-config-fluid has a dependency on eslint-plugin-jsdoc: ~39.3.0, which is incompatible with the new version of node we're using. 0.28.2000 doesn't have that dependency, and since it was being used by other packages I downgraded this.

Okay. Let's note this and similar work arounds in the PR description.

Good call - added a list of workarounds used to the description

jason-ha · 2025-09-24T18:40:38Z

build-tools/package.json

  "devDependencies": {
    "@microsoft/api-documenter": "^7.17.9",
-    "@microsoft/api-extractor": "^7.22.2",
+    "@microsoft/api-extractor": "~7.22.2",


Wish we had comments in package.json. What is this api-extractor ~ for?

This was a workaround for a strange api-extractor issue we were seeing. The problem was when using ^7.22.2, api-extractor was somehow pulling in an incompatible version of typescript to parse the source files and threw errors when parsing. Strangely, even using the --typescript-compiler-folder switch in the run options and setting the version of TS to use wasn't enough. Scott found this workaround of using ~ solved the problem

jason-ha · 2025-09-24T18:43:47Z

examples/apps/spaces/tests/spaces.test.ts

    });

-    it("There's a button to be clicked", async () => {
+    it.skip("There's a button to be clicked", async () => {


jason-ha · 2025-09-24T18:50:06Z

examples/hosts/app-integration/schema-upgrade/src/appView.tsx

    };

    let importedDataView;
+


This is fine but why any change?

Looks like I introduced this space while finding a version of eslint + configs that worked under the new config. One config tried making this + subsequent lines a giant ternary statement which ended up violating other rules, so I added // eslint-disable-next-line unicorn/prefer-ternary here, and then later when I had a different config set it didnt try condensing this into a ternary, so the rule was removed but the space remained. I'll remove that space

jason-ha · 2025-09-24T18:52:56Z

package.json

-    "build:ci": "npm run build:genver && lerna run build:compile --stream",
-    "build:compile": "lerna run build:compile --stream",
-    "build:docs": "lerna run build:docs --stream --parallel",
+    "build": "npm run policy-check && npm run build:genver && npm run build:compile && npm run lint && npm run build:docs",


maybe "echo skip layer-check" instead of just removing?

And if we're skipping layer check, does something else need layerInfo.json?

Good calls. Added that echo and removed layerInfo.json

alexvy86

Went through some of the more mechanical changes, left a few comments. I'd like to still go over the pipeline definitions in more detail when I have time but can't promise I will soon; don't want to be a bottleneck though.

packages/common/container-definitions/package.json

packages/dds/quorum/.eslintrc.js

alexvy86 · 2025-09-25T00:04:11Z

packages/dds/shared-object-base/src/sharedObject.ts

+        assert(
+            this.mc !== undefined && this.logger !== undefined,
+            0x348, /* this.mc and/or this.logger has not been set */
+        );


Did we have tag asserts in this branch? If not necessary I'd recommend reverting this just to avoid introducing functional changes.

I don't think we do - given the added assertionShortCodesMap that got added automatically when I tested, and it picked out a bunch of assert messages when it ran, I think we can undo the output from the assert tagging tool. Will update PR in a bit

I take it back - it looks like we did have assert tagging. Most of these messages were pre-existing (turns out everything got highlighted because the linter decided to turn spaces to tabs. Here's the file on LTS prior to my changes: https://github.com/microsoft/FluidFramework/blob/lts/packages/runtime/test-runtime-utils/src/assertionShortCodesMap.ts )

My change did add a couple more assertion tags though, so I'm guessing a few asserts were added in and never got tagged. I also would prefer not to have any functional changes in this PR so I'm still good with undoing the new tags

alexvy86 · 2025-09-25T00:06:47Z

package.json

-    "build:ci": "npm run build:genver && lerna run build:compile --stream",
-    "build:compile": "lerna run build:compile --stream",
-    "build:docs": "lerna run build:docs --stream --parallel",
+    "build": "npm run policy-check && npm run build:genver && npm run build:compile && npm run lint && npm run build:docs",


And if we're skipping layer check, does something else need layerInfo.json?

alexvy86 · 2025-09-25T00:09:08Z

package.json

-    "node": ">=18.17.1",
-    "npm": "^6.14.18"
+    "node": ">=20.15.1",
+    "npm": "^6.14.18",


This line should be removable, I think?

Bump on this one.

I think it should be, yeah. Removing

jumyhre · 2025-09-25T18:46:52Z

Went through some of the more mechanical changes, left a few comments. I'd like to still go over the pipeline definitions in more detail when I have time but can't promise I will soon; don't want to be a bottleneck though.

Thanks for reviewing! No need to rush - it looks like I missed a couple pipelines that I need to update anyways before this is done

…cho message, adds comment to disabled test, fixes bad prev version typetest and linter change

alexvy86 · 2025-09-25T22:56:12Z

azure/packages/azure-client/package.json

+		"@microsoft/api-extractor": "~7.34.4",
 		"@types/mocha": "^9.1.1",
-		"@types/node": "^18.15.3",
+		"@types/node": "^14.18.0",


Why did we have to downgrade @types/node back to 14 at the same time as bumping node to 20?

The types/node change was easily my least favorite change. I tried using a node types file that matched the version of node we're using now. Doing so raised tons of compilation errors in other packages -- which weren't actual errors -- inside the types definitions of that node version. Here's a snippet of the output I get when I change this one package back to using 18.15.3:

packages/common/driver-definitions build:compile: [build:esnext] ~ packages/common/driver-definitions build:compile: [build:esnext] packages/common/driver-definitions build:compile: [build:esnext] ../../../node_modules/.pnpm/@[email protected]/node_modules/@types/node/http2.d.ts:1177:21 - error TS1005: ',' expected. packages/common/driver-definitions build:compile: [build:esnext] packages/common/driver-definitions build:compile: [build:esnext] 1177 listener: ( packages/common/driver-definitions build:compile: [build:esnext] ~ packages/common/driver-definitions build:compile: [build:esnext] packages/common/driver-definitions build:compile: [build:esnext] ../../../node_modules/.pnpm/@[email protected]/node_modules/@types/node/http2.d.ts:1180:22 - error TS1109: Expression expected. packages/common/driver-definitions build:compile: [build:esnext] packages/common/driver-definitions build:compile: [build:esnext] 1180 ) => void, packages/common/driver-definitions build:compile: [build:esnext] ~ packages/common/driver-definitions build:compile: [build:esnext] packages/common/driver-definitions build:compile: [build:esnext] ../../../node_modules/.pnpm/@[email protected]/node_modules/@types/node/http2.d.ts:1181:10 - error TS1005: ';' expected. packages/common/driver-definitions build:compile: [build:esnext] packages/common/driver-definitions build:compile: [build:esnext] 1181 ): this; packages/common/driver-definitions build:compile: [build:esnext] ~ packages/common/driver-definitions build:compile: [build:esnext] packages/common/driver-definitions build:compile: [build:esnext] ../../../node_modules/.pnpm/@[email protected]/node_modules/@types/node/http2.d.ts:1183:18 - error TS1005: ',' expected. packages/common/driver-definitions build:compile: [build:esnext] packages/common/driver-definitions build:compile: [build:esnext] 1183 event: "stream", packages/common/driver-definitions build:compile: [build:esnext] ~ packages/common/driver-definitions build:compile: [build:esnext] packages/common/driver-definitions build:compile: [build:esnext] ../../../node_modules/.pnpm/@[email protected]/node_modules/@types/node/http2.d.ts:1184:21 - error TS1005: ',' expected. packages/common/driver-definitions build:compile: [build:esnext] packages/common/driver-definitions build:compile: [build:esnext] 1184 listener: (stream: ServerHttp2Stream, headers: IncomingHttpHeaders, flags: number) => void, packages/common/driver-definitions build:compile: [build:esnext] ~ packages/common/driver-definitions build:compile: [build:esnext] packages/common/driver-definitions build:compile: [build:esnext] [... continues on...]

The d.ts files are fine, so it shouldnt be throwing errors. I spent a lot of investigation trying to figure this out. I tried to work around it by adding skip lib check options to typescript compilation, but that still didnt work (?!). At this point I looked at main for any inspiration and found main was also using node types from an old version (main's min node is 20.15.1, but most packages use [email protected], and I also spotted this comment in main's package.json: "@types/node is ignored because it is usually not needed by packages, and if it is, then the package will hit a compilation failure.".

At this point I'd been banging my head against a wall on this issue for a couple days and timeboxed it - it looked like main wasn't in an ideal state either, setting everything to node 14.18.0 "worked", so that's how we got here. It's not exactly ideal, I agree.

and note that these errors-which-arent-actually-errors will show up regardless of the version of types/node I use. Trying a more recent types/node for node 20 throws the same stuff:

.../data-objects/multiview/interface build:compile: ../../../../node_modules/.pnpm/@[email protected]/node_modules/@types/node/http2.d.ts:1185:10 - error TS1005: ';' expected. .../data-objects/multiview/interface build:compile: 1185 ): this; .../data-objects/multiview/interface build:compile: ~ .../data-objects/multiview/interface build:compile: ../../../../node_modules/.pnpm/@[email protected]/node_modules/@types/node/http2.d.ts:1186:17 - error TS1005: ',' expected. .../data-objects/multiview/interface build:compile: 1186 on(event: string | symbol, listener: (...args: any[]) => void): this; .../data-objects/multiview/interface build:compile: ~ .../data-objects/multiview/interface build:compile: ../../../../node_modules/.pnpm/@[email protected]/node_modules/@types/node/http2.d.ts:1186:44 - error TS1005: ',' expected. .../data-objects/multiview/interface build:compile: 1186 on(event: string | symbol, listener: (...args: any[]) => void): this; .../data-objects/multiview/interface build:compile: ~ .../data-objects/multiview/interface build:compile: ../../../../node_modules/.pnpm/@[email protected]/node_modules/@types/node/http2.d.ts:1186:70 - error TS1109: Expression expected. .../data-objects/multiview/interface build:compile: 1186 on(event: string | symbol, listener: (...args: any[]) => void): this; .../data-objects/multiview/interface build:compile: ~ .../data-objects/multiview/interface build:compile: ../../../../node_modules/.pnpm/@[email protected]/node_modules/@types/node/http2.d.ts:1186:71 - error TS1005: ';' expected. .../data-objects/multiview/interface build:compile: 1186 on(event: string | symbol, listener: (...args: any[]) => void): this; .../data-objects/multiview/interface build:compile: ~

packages/dds/tree/package.json

alexvy86 · 2025-09-25T23:25:06Z

packages/test/test-end-to-end-tests/src/test/messageSize.spec.ts

@@ -84,7 +84,7 @@ describeNoCompat("Message size", (getTestObjectProvider) => {
    const containerError = async (container: IContainer) =>
        new Promise<IErrorBase | undefined>((resolve) => container.once("closed", (error) => { resolve(error); }));

-    itExpects("A large op will close the container with chunking disabled", [
+    itExpects.skip("A large op will close the container with chunking disabled", [


alexvy86 · 2025-09-25T23:25:35Z

packages/test/test-end-to-end-tests/src/test/rootDatastores.spec.ts

@@ -175,7 +175,7 @@ describeNoCompat("Named root data stores", (getTestObjectProvider) => {
            assert(await dataCorruption);
        });

-        it("Root datastore creation with aliasing turned on throws exception", async () => {
+        it.skip("Root datastore creation with aliasing turned on throws exception", async () => {


And more comments :).

…d tools version, and adding release group tag to test tools pipeline

…me for release group

alexvy86 · 2025-09-30T16:01:12Z

packages/utils/telemetry-utils/package.json

-    "@fluidframework/telemetry-utils-previous": "npm:@fluidframework/[email protected]",
-    "@microsoft/api-extractor": "^7.22.2",
+    "@fluidframework/mocha-test-setup": "workspace:~",
+    "@fluidframework/telemetry-utils-previous": "npm:@fluidframework/[email protected]",


The previous versions for everything should be 1.3.1, no?

Yep, that should be 1.3.1 still. Fixed, thanks!

alexvy86 · 2025-09-30T16:02:40Z

packages/utils/tool-utils/package.json

-    "@fluidframework/tool-utils-previous": "npm:@fluidframework/[email protected]",
-    "@microsoft/api-extractor": "^7.22.2",
+    "@fluidframework/mocha-test-setup": "workspace:~",
+    "@fluidframework/tool-utils-previous": "npm:@fluidframework/[email protected]",


Another previous that I think should be 1.3.1.

It should be. It turns out that there's another issue with this package's typetests - using 1.3.1 introduces this compilation issue in the typetest generated code:

[build:compile] [build:commonjs] dist/odspTokenManager.d.ts:5:23 - error TS2305: Module '"@fluidframework/odsp-doclib-utils"' has no exported member 'IPublicClientConfig'. [build:compile] [build:commonjs] [build:compile] [build:commonjs] 5 import { IOdspTokens, IPublicClientConfig } from "@fluidframework/odsp-doclib-utils";

It looks like IPublicClientConfig doesn't exist in 1.3.1, but it's unclear to me why typescript is only now finding a fault with this project when it worked using lerna. I spent a couple hours of best effort trying to resolve the issue with no luck. I've disabled the typetests for tool-utils in the latest update to work around the issue

packages/common/core-interfaces/tsconfig.json

packages/common/core-interfaces/tsconfig.esnext.json

packages/utils/tool-utils/src/test/tsconfig.json

api-report/merge-tree.api.md

experimental/PropertyDDS/packages/property-changeset/src/utils.ts

experimental/PropertyDDS/packages/property-properties/src/propertyFactory.js

alexvy86 · 2025-09-30T16:31:08Z

experimental/PropertyDDS/packages/property-properties/src/propertyTemplate.js

                (_.isArray(in_obj) !== _.isArray(target)) ||
                !_.isObject(target)) {
-                throw new Error(
+                throw new TypeError(


Here and 236 also go back to Error.

Missed this line :)

…, updates common-utils' build-tools dependency and typetest generation

…st gen for new build tools

…utils

…tils typetest to work around unexpected ocmpilation issue

alexvy86

Ok, a few more comments, and I'm done looking through everything except the pipeline definition files. Since they still seem to need tweaks, I'll wait on those.

alexvy86 · 2025-10-01T17:14:00Z

packages/framework/tinylicious-client/src/test/TinyliciousClient.spec.ts

        const containerId = await containerCreate.attach();
-        await new Promise<void>((resolve, reject) => {
+        await timeoutPromise((resolve, reject) => {


Can you elaborate on the changes to this file?

With the package updates, this test started failing. I strongly suspected the issue was a correctness issue with the test itself - debugging showed it was actually doing the op it was supposed to, but then moved on to assert before everything was settled. When I looked at this test on main (source:

FluidFramework/packages/service-clients/tinylicious-client/src/test/TinyliciousClient.spec.ts

Line 220 in ddaa356

it("can change initialObjects value", async function () {

) I found this crucial bit of code in main:

// Make sure the op round tripped await timeoutPromise((resolve, reject) => { if (!containerCreate.isDirty) { resolve(); } containerCreate.on("saved", () => { resolve(); }); });

Copying this impl from main resolved the test issue

alexvy86 · 2025-10-01T17:20:00Z

experimental/dds/tree/assertTagging.config.mjs

Why the need for these files? Here, in runtime/test-runtime-utils, and in test-end-to-end-tests (which shouldn't have taggable asserts).

You're right, they shouldnt - the problem was when I ran the assert tagging tool, it tried to tag these test files with asserts. I added these assertTagging.config.mjs files to ensure they would be skipped.

alexvy86 · 2025-10-01T17:23:00Z

packages/test/test-end-to-end-tests/package.json

@@ -28,19 +28,19 @@
    "test:realsvc": "npm run test:realsvc:local && npm run test:realsvc:tinylicious",
    "test:realsvc:frs": "npm run test:realsvc:run -- --driver=r11s --r11sEndpointName=frs --timeout=20s",
    "test:realsvc:frs:report": "cross-env FLUID_TEST_REPORT=1 npm run test:realsvc:frs --",
-    "test:realsvc:local": "npm run test:realsvc:run -- --driver=local",
+    "test:realsvc:local": "npm run test:realsvc:run -- --driver=local --baseVersion=1.4.0",


Do we need baseVersion explicitly? Docs suggest that it would default to the current version of the package.

it should default to the current package version, and actually does when run locally, but the problem I found was these tests didnt use the current version when run on CI. I banged my head against this wall for a good day and a half and ended up using this workaround to resolve the CI failure

alexvy86 · 2025-10-01T17:24:45Z

packages/test/test-end-to-end-tests/package.json

    "test:realsvc:local:report": "cross-env FLUID_TEST_REPORT=1 npm run test:realsvc:local --",
    "test:realsvc:odsp": "npm run test:realsvc:run -- --driver=odsp --timeout=20s",
    "test:realsvc:odsp:report": "cross-env FLUID_TEST_REPORT=1 npm run test:realsvc:odsp --",
-    "test:realsvc:r11s": "npm run test:realsvc:run -- --driver=r11s --use-openssl-ca",
+    "test:realsvc:r11s": "npm run test:realsvc:run -- --driver=r11s --use-openssl-ca --timeout=20s",


Don't mind it but checking if it's strictly necessary to make tests pass.

Not strictly necessary, but useful - I was finding that both CI and local test runs were timing out frequently enough that I added this timeout to reduce noise.

jumyhre · 2025-10-01T18:46:36Z

Ok, a few more comments, and I'm done looking through everything except the pipeline definition files. Since they still seem to need tweaks, I'll wait on those.

Thank you for the review! The pipeline files are nearly resolved - will ping you once everything's working

…to what is done on main)

…ks dont work here

jumyhre · 2025-10-02T17:11:56Z

Ok, a few more comments, and I'm done looking through everything except the pipeline definition files. Since they still seem to need tweaks, I'll wait on those.

Pipelines are now stabilized and ready for review!

alexvy86

Alright, done reviewing everything 😄 .

Hopefully last batch of comments. One general one: I didn't look at the lockfile changes under common/, updating package-lock.json from v1 to v3. I'd be slightly concerned about those but one of my comments suggests undoing all the changes under common/ so if we can do that, I think it's probably best.

alexvy86 · 2025-10-10T17:20:38Z

common/lib/common-definitions/package.json

Seems like we missed updating the lockfile for this. Although actually, maybe we should consider not updating anything under common/lib/ to minimize churn since those packages are managed separately from the actual FF client code (release group). In main, common/build/ actually matters for the build of the client release group, but in LTS I don't think that's the case? And if so, I think maybe we should skip the changes there too.

Yeah, you're right, we shouldnt need any changes to the common directory. I've reverted all changes

alexvy86 · 2025-10-10T17:30:22Z

experimental/PropertyDDS/packages/property-properties/src/propertyTemplate.js

                (_.isArray(in_obj) !== _.isArray(target)) ||
                !_.isObject(target)) {
-                throw new Error(
+                throw new TypeError(


Missed this line :)

alexvy86 · 2025-10-10T17:31:09Z

package.json

-    "node": ">=18.17.1",
-    "npm": "^6.14.18"
+    "node": ">=20.15.1",
+    "npm": "^6.14.18",


Bump on this one.

package.json

tools/pipelines/repo-policy-check.yml

tools/pipelines/templates/build-npm-package.yml

tools/pipelines/templates/include-publish-npm-package-deployment.yml

alexvy86 · 2025-10-10T17:55:22Z

tools/pipelines/templates/include-publish-npm-package-deployment.yml

+              script: |
+                echo "installing version @${{ parameters.buildToolsVersionToInstall }}"
+
+                npm install --global "@fluid-tools/build-cli@${{ parameters.buildToolsVersionToInstall }}"


I assume this install of build-tools is what needs us to keep the step above that installs npm; I'd argue for removing that step otherwise (like I did in other comments for other yaml files). But if we need it, can we use a consistent version everywhere? npm@10 like the others instead of 6.

Yep, we do need this. I think we can use a consistent npm version everywhere though, will update existing npm 6s to 10s

alexvy86 · 2025-10-10T17:58:46Z

tools/pipelines/templates/include-publish-npm-package-deployment.yml

-              artifactPath: scoped
-              feedName: ${{ parameters.feedName }}
+              artifactPath: tarballs
+              feedKind: ${{ parameters.feedKind }}


It's very hard to tell if the actual publishing of packages actually works without exercising it; after we merge the PR we'll at least we'll know if publishing to our internal feeds works as expected. At that point maybe doing a "no-op patch" (no-changes) release of the 1.x packages might be a good exercise just to make sure we can actually release them quickly if we ever need to. So nothing to address for this comment, just a thought.

Agreed, I'd like to see the publishing pipelines all working. I think that's a good thing to try out once this is committed. For what its worth, the publish internal test packages step works when I test this on the internal pipelines: https://dev.azure.com/fluidframework/internal/_build/results?buildId=360083&view=logs&j=88a4f9f3-7925-540d-9db1-365e924a72d7 , so I'm crossing my fingers that the'll translate over to the client publish too

…nstalls, removing packageManagerInstallCommand in favor of hardcoded pnpm i

alexvy86

To the best of my reviewing ability + bandwidth, this looks fine. 🚀

jumyhre · 2025-10-10T23:22:55Z

To the best of my reviewing ability + bandwidth, this looks fine. 🚀

Thank you for reviewing!

Going to merge on Monday, just to avoid any potential pipeline failures over the weekend

jumyhre added 2 commits September 23, 2025 10:47

removing unneeded changes to server/ and tools/ packages

6de6656

jumyhre requested review from a team and msfluid-bot as code owners September 24, 2025 18:23

jumyhre commented Sep 24, 2025

View reviewed changes

jason-ha reviewed Sep 24, 2025

View reviewed changes

alexvy86 reviewed Sep 25, 2025

View reviewed changes

jumyhre added 2 commits September 25, 2025 13:33

PR fixes: Removes layerInfo.json, disables layer-check step with an e…

be18766

…cho message, adds comment to disabled test, fixes bad prev version typetest and linter change

undoing assert tagging changes

f8f1432

alexvy86 reviewed Sep 25, 2025

View reviewed changes

jumyhre added 2 commits September 29, 2025 13:33

Setting build-common and test-tools pipelines to use most recent buil…

f3acd7a

…d tools version, and adding release group tag to test tools pipeline

Updating benchmark tool pipeline to use newer build tools, adds tagNa…

04c554e

…me for release group

alexvy86 reviewed Sep 30, 2025

View reviewed changes

jumyhre added 4 commits September 30, 2025 11:14

Updates pipelines to use npm version concurrent with node 20 (npm 10)…

8ee48b6

…, updates common-utils' build-tools dependency and typetest generation

Updating two more pipelines to use most recent build-tools

4909a02

Updates protocol-definitions to use build-tools 0.55.0,updates typete…

bc430b0

…st gen for new build tools

removing unneeded flags from tsconfigs in common-interfaces and tool-…

066ec1f

…utils

jumyhre added 4 commits September 30, 2025 15:23

Undoing linter error and unwanted changes to error type

ceed675

removing this is ISegment from merge-tree sources

a13435e

Reverting telemetry-utils typetest version to 1.3.1, disabling tool-u…

c0fec6d

…tils typetest to work around unexpected ocmpilation issue

Disabling type tests in tool-utils, removing typetest gen file

45b6fb8

alexvy86 reviewed Oct 1, 2025

View reviewed changes

jumyhre added 2 commits October 1, 2025 10:57

Adding comments to disabled end to end tests

ba6188f

updating lockfile

9e93107

jumyhre added 8 commits October 1, 2025 11:49

Updating common-utils build pipeline to latest build tools version

7ec3179

Updating eslint-config-fluid package lockfile to npm 10

ccaf42d

Updates bundle stat scripts to use flub, adds danger dep

bfc99b3

adds continueOnError to run bundle size task of build steps (similar …

d43ff41

…to what is done on main)

Updating repo-policy-check pipeline to use node 20.15.1 + npm 10

ca06624

Using repo-policy-check pipeline from main, without layer check

123e0fa

removing build-tools sources and associated build pipeline

63fae83

removing CG steps - the LTS pipeline wasnt doing that, main's CG chec…

227dfe7

…ks dont work here

alexvy86 reviewed Oct 10, 2025

View reviewed changes

jumyhre added 6 commits October 10, 2025 11:57

Reverting error type change in propertyTemplate

bfd06a4

reverting all changes to common directory

9298bee

reverting danger dependency

da53be3

updating all pipeline scripts to npm 10, removing some unneeded npm i…

bcd97e5

…nstalls, removing packageManagerInstallCommand in favor of hardcoded pnpm i

restoring packageManagerInstallCommand to pipelines

fec4c52

removing new typetest files from common

df0fda2

alexvy86 approved these changes Oct 10, 2025

View reviewed changes

jumyhre merged commit ffd8c55 into lts Oct 13, 2025
13 checks passed

jumyhre deleted the jumyhre/ltsUsingPnpm branch October 13, 2025 15:05

		@@ -8,693 +8,698 @@
		// Auto-generated by policy-check in @fluidframework/build-tools.

		export const shortCodeMap = {

Replacing Lerna with pnpm on LTS #25537

Replacing Lerna with pnpm on LTS #25537

Uh oh!

Conversation

jumyhre commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jason-ha left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexvy86 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jumyhre commented Sep 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jumyhre commented Sep 24, 2025 •

edited

Loading