Merge pull request #3065 from pnp/version-4

Release 4.1.1 Patch to fix latest version on npmjs

.github/workflows/publish.yml

@@ -11,12 +11,10 @@ jobs:
     # Steps represent a sequence of tasks that will be executed as part of the job
     steps:
       # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
-      - uses: actions/checkout@v4
-        with:
-          ref: main    
+      - uses: actions/checkout@v4  
       # setup nodejs
       - name: Use Node.js 18
-        uses: actions/setup-node@v3
+        uses: actions/setup-node@v4
         with:
           node-version: 18
           registry-url: 'https://registry.npmjs.org'
@@ -31,6 +29,6 @@ jobs:
         run: |
           npm run clean
           npm run package
-          npm run just-publish
+          npm run just-publish      
         env:
           NODE_AUTH_TOKEN: ${{ secrets.NPM_PUBLISH_TOKEN }}

CHANGELOG.md

@@ -5,6 +5,13 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
 and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
 
+## 4.1.1 - 2024-June-05
+
+### Fixed
+
+- graph
+  - Fixed batching issues that fails when batched call returns 204
+
 ## 4.1.0 - 2024-May-24
 
 ### Fixed

docs/concepts/batching.md

@@ -217,41 +217,3 @@ await execute();
 ```
 
 > In addition you cannot continue using a batch after execute. Once execute has resolved the batch is done. You should create a new batch using one of the described methods to conduct another batched call.
-
-## Case where batch result returns an object that can be invoked
-
-In the following example, the results of adding items to the list is an object with a type of **IItemAddResult** which is `{data: any, item: IItem}`. Since version v1 the expectation is that the `item` object is immediately usable to make additional queries. When this object is the result of a batched call, this was not the case so we have added additional code to reset the observers using the original base from witch the batch was created, mimicing the behavior had the **IItem** been created from that base withyout a batch involved. We use [CopyFrom](../core/behaviors.md#CopyFrom) to ensure that we maintain the references to the InternalResolve and InternalReject events through the end of this timelines lifecycle.
-
-```TypeScript
-import { createBatch } from "@pnp/sp/batching";
-import { SPDefault } from "@pnp/nodejs";
-import { IList } from "@pnp/sp/lists";
-import "@pnp/sp/items/list";
-
-const sp = spfi("https://tenant.sharepoint.com/sites/dev").using(SPDefault({ /* ... */ }));
-
-// in one part of your application you setup a list instance
-const list: IList = sp.web.lists.getByTitle("MyList");
-
-const [batchedListBehavior, execute] = createBatch(list);
-// this list is now batching all its requests
-list.using(batchedListBehavior);
-
-let res: IItemAddResult[] = [];
-
-// these will all occur within a single batch
-list.items.add({ Title: `1: ${getRandomString(4)}` }).then(r => res.push(r));
-list.items.add({ Title: `2: ${getRandomString(4)}` }).then(r => res.push(r));
-list.items.add({ Title: `3: ${getRandomString(4)}` }).then(r => res.push(r));
-list.items.add({ Title: `4: ${getRandomString(4)}` }).then(r => res.push(r));
-
-await execute();
-
-let newItems: IItem[] = [];
-
-for(let i=0; i<res.length; i++){
-    //This line will correctly resolve
-    const newItem = await res[i].select("Title")<{Title: string}>();
-    newItems.push(newItem);
-}
-```

docs/graph/taxonomy.md

@@ -32,36 +32,6 @@ const graph = graphfi(...);
 // get term store data
 const info: ITermStoreInfo = await graph.sites.getById("contoso.sharepoint.com,91dd2418-8fb9-4e0e-919d-c1b31e938386,285cc5a1-cf50-4e4d-8d93-5ba5a8e76e01").termStore();
 
-```
-### SearchTerm
-
-Search for terms starting with provided label under entire termStore or a termSet or a parent term.
-
-The following properties are valid for the supplied query: `label: string`, `setId?: string`, `parentTermId?: string`, `languageTag?: string`, `stringMatchOption?: "ExactMatch" | "StartsWith"`.
-
-```TypeScript
-import { graphfi } from "@pnp/graph";
-import "@pnp/graph/taxonomy";
-
-const graph = graphfi(...);
-
-// minimally requires the label
-const results1 = await graph.termStore.searchTerm({
-  label: "test",
-});
-
-// other properties can be included as needed
-const results2 = await graph.termStore.searchTerm({
-  label: "test",
-  setId: "{guid}",
-});
-
-// other properties can be included as needed
-const results3 = await graph.termStore.searchTerm({
-  label: "test",
-  setId: "{guid}",
-  stringMatchOption: "ExactMatch",
-});
 ```
 
 ### Update
@@ -404,8 +374,6 @@ const termInfo2 = await graph.termStore.groups.getById("338666a8-1111-2222-3333-
 
 ### Delete
 
-_Added in 3.10.0_
-
 ```TypeScript
 import { graphfi, SPFxToken, SPFx } from "@pnp/graph";
 import "@pnp/graph/taxonomy";

docs/sp/items.md

@@ -194,17 +194,16 @@ import { spfi } from "@pnp/sp";
 import "@pnp/sp/webs";
 import "@pnp/sp/lists";
 import "@pnp/sp/items";
-import { IItemAddResult } from "@pnp/sp/items";
 
 const sp = spfi(...);
 
 // add an item to the list
-const iar: IItemAddResult = await sp.web.lists.getByTitle("My List").items.add({
+const item = await sp.web.lists.getByTitle("My List").items.add({
   Title: "Title",
   Description: "Description"
 });
 
-console.log(iar);
+console.log(item);
 ```
 
 ### Content Type

docs/transition-guide.md

@@ -13,7 +13,9 @@ To better support Taxonomy authentication and control we've moved our Taxonomy i
 
 ## Add/Update methods no longer returning data and a queryable instance
 
-The primary breaking change will be with add and update method return values. We are not going to return what the calling endpoint returns so anywhere that you are referencing the return objects `data` property you will need to remove that reference. Many of the graph endpoints do return the added or updated object but most of the SharePoint ones return 204, which would translate into a return type of void.
+The primary breaking change will be with add and update method return values. We are going to return what the calling endpoint returns in all cases instead of an object that includes data property and an "item" property. This means anywhere that you are referencing the return objects `data` property you will need to remove that reference. Many of the graph endpoints return the added or updated object so, other than changing the reference this will not impact your code.
+
+SharePoint returns the object for add events but many update events return 204, which would translate into a return type of void. In that case you will have to adjust your code to make a second call if you want to validate that the item has been updated:
 
 Ex:
 
@@ -23,10 +25,24 @@ Ex:
     const newTitle = update.data.Title;
 
     // Version 4
-    await sp.web.lists.getByTitle("My List").items.getById(1)..update({Title: "My New Title"});
+    await sp.web.lists.getByTitle("My List").items.getById(1).update({Title: "My New Title"});
     const updatedItem = await sp.web.lists.getByTitle("My List").items.getById(1)();
     ```
 
+As stated before, when adding items in both graph and SharePoint the call will return the object that was created. So you can get the newly created objects `id` by simply referencing it directly:
+
+Ex:
+
+    ```TypeScript
+    // Version 3 
+    const newItem = await sp.web.lists.getByTitle("My List").items.add({Title: "My New Title"});
+    const newItemId = newItem.data.Id;
+
+    // Version 4
+    const newItem = await sp.web.lists.getByTitle("My List").items.add({Title: "My New Title"});
+    const newItemId = newItem.Id;
+    ```
+
 ## Async Iterator Pattern
 
 As an updated pattern we are recommending you move to an async iterator pattern to get more than 5000 items from a list.