Merge pull request SharePoint#7916 from StephenBrentPeters/patch-1

[BrokenLinksH2] fixing broken link

Author: andrewconnell

docs/spfx/team-based-development-on-sharepoint-framework.md

@@ -1,7 +1,7 @@
 ---
 title: Team-based development on the SharePoint Framework
 description: Prepare your dev environment, work with internal packages, ensure code consistency and quality, and upgrade projects.
-ms.date: 07/21/2020
+ms.date: 04/28/2022
 ms.prod: sharepoint
 ms.localizationpriority: high
 ---
@@ -108,7 +108,7 @@ A new SharePoint Framework project scaffolded by the SharePoint Framework Yeoman
 
 A common solution to avoid the risk of dependencies changing during the project, in projects built on the open-source toolchain, is to lock the version of all dependencies. When adding a dependency to the project developers can choose to install the dependency with a specific version rather than a version range by calling the **npm install** command with the **--save-exact** argument.
 
-This however doesn't affect the child dependencies of the particular package. To effectively lock the version of all dependencies and their children in the project, developers can use the native lock file capability supported by NPM. For more information, see [npm-package-locks: An explanation of NPM lock files](https://docs.npmjs.com/configuring-npm/package-locks.html).
+This however doesn't affect the child dependencies of the particular package. To effectively lock the version of all dependencies and their children in the project, developers can use the native lock file capability supported by NPM. For more information, see [npm-package-locks: An explanation of NPM lock files](https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json).
 
 ### Add the project to source control
 
@@ -138,7 +138,7 @@ Using existing packages to accomplish specific tasks allows you to be more produ
 > [!IMPORTANT]
 > Since there's no formal verification process before a package is published to **https://www.npmjs.com**, you should carefully examine if you can use the particular package both from the contents and license point of view.
 
-To add a package to your SharePoint Framework project execute the **npm install <package> --save** or **npm install <package> --save-dev** command in the command line, for example: **npm install angular --save**. Using the **--save** or **--save-dev** argument ensures that the package is added to the **package.json** file and other developers on your team will get it as well when restoring dependencies. Without it building the project on a machine other than your own will fail. When adding packages that are required by your solution on runtime, such as Angular or jQuery, you should use the **--save** argument. Packages that are required in the build process, such as additional Gulp tasks, should be installed with the **--save-dev** argument.
+To add a package to your SharePoint Framework project execute the **npm install {package} --save** or **npm install {package} --save-dev** command in the command line, for example: **npm install angular --save**. Using the **--save** or **--save-dev** argument ensures that the package is added to the **package.json** file and other developers on your team will get it as well when restoring dependencies. Without it building the project on a machine other than your own will fail. When adding packages that are required by your solution on runtime, such as Angular or jQuery, you should use the **--save** argument. Packages that are required in the build process, such as additional Gulp tasks, should be installed with the **--save-dev** argument.
 
 When installing a package, if you don't specify a version, npm will install the latest version available in the package registry (**https://www.npmjs.com** by default), which usually is the version that you'll want to use. One specific case when you have to specify the version of the package is when you're using **npm-shrinkwrap.json** and want to upgrade an existing package to a newer version. By default npm will install the version listed in the **npm-shrinkwrap.json** file. Specifying the version number in the **npm install** command, like **npm install [email protected] --save**, will install that package and update the version number in the **npm-shrinkwrap.json** file.
 
@@ -154,7 +154,7 @@ When using private package registries organizations can choose between different
 
 Using a private package registry allows organizations to centrally manage common code used across the different projects. By defining a separate governance plan around contributing changes to the shared code base, organizations can ensure that the code library is of high quality and that it offers all developer benefits as intended rather than being a burden slowing projects down.
 
-Organizations using Visual Studio Team Services or the Team Foundation Server, can conveniently [create a private npm registry directly in VSTS/TFS](https://docs.microsoft.com/vsts/package/overview). Organizations using other source control systems, can use other solutions for hosting their packages. A popular private registry hosted in the cloud is [npm Enterprise](https://www.npmjs.com/enterprise). Organizations that are interested in hosting their registry themselves can choose from a number of open-source implementations such as [Sinopia](https://github.com/rlidwka/sinopia) or its fork [Verdaccio](https://github.com/verdaccio/verdaccio) or [Nexus](https://www.sonatype.com/nexus-repository-oss).
+Organizations using Visual Studio Team Services or the Team Foundation Server, can conveniently [create a private npm registry directly in VSTS/TFS](/vsts/package/overview). Organizations using other source control systems, can use other solutions for hosting their packages. A popular private registry hosted in the cloud is [npm Enterprise](https://www.npmjs.com/enterprise). Organizations that are interested in hosting their registry themselves can choose from a number of open-source implementations such as [Sinopia](https://github.com/rlidwka/sinopia) or its fork [Verdaccio](https://github.com/verdaccio/verdaccio) or [Nexus](https://www.sonatype.com/nexus-repository-oss).
 
 > [!NOTE]
 > Different engines for hosting private package registries are in different development stages and you should carefully evaluate that the particular engine meets your requirements, both from the functionality, license and support point of view.
@@ -166,7 +166,7 @@ To simplify the installation and management of a private package registry, most
 An alternative to using a private registry is linking packages. While it doesn't involve setting up a registry, it requires careful coordination on all developer machines and the build server.
 
 First, every developer on the team must get a copy of the shared package on their development machine. In the command line, they have to change the working directory to the one of the shared packages and then they must execute the **npm link** command. This command registers the particular package as a global package on that particular development machine.
-Next, developers have to change the working directory to the directory of the project in which they would like to use the shared package. Then they install the package the same way they would install any other package by executing the **npm install <shared_package> --save** command in the command line. As the shared package is installed globally, npm will use that version as the source to install the package from. At this point, from the project point of view, the package is installed just like any other public package and developers can choose how they want to bundle the package with the project.
+Next, developers have to change the working directory to the directory of the project in which they would like to use the shared package. Then they install the package the same way they would install any other package by executing the **npm install {shared_package} --save** command in the command line. As the shared package is installed globally, npm will use that version as the source to install the package from. At this point, from the project point of view, the package is installed just like any other public package and developers can choose how they want to bundle the package with the project.
 
 Linking the package must be executed on all development machines and on the build server. If the shared package isn't linked using the **npm link** command, restoring project dependencies will fail and break the build.
 
@@ -256,10 +256,10 @@ SharePoint Framework solutions are deployed using an **\*.sppkg** file installed
 
 ### Update dependencies
 
-One of the reasons for an update of a SharePoint Framework project might be a change to one of the underlying dependencies, for example a new release of Angular with bug fixes and performance improvements. If your team follows the recommended approach of using npm shrinkwrap for locking dependency versions, then you would use the **npm install <package>@<version> --save** command to update your dependency to the specific version and test your project to verify that it works as expected with the latest updates. Depending on how the changes to the underlying dependencies impact the project, the overall project update might vary from a patch to a full major release.
+One of the reasons for an update of a SharePoint Framework project might be a change to one of the underlying dependencies, for example a new release of Angular with bug fixes and performance improvements. If your team follows the recommended approach of using npm shrinkwrap for locking dependency versions, then you would use the **npm install {package}@{version} --save** command to update your dependency to the specific version and test your project to verify that it works as expected with the latest updates. Depending on how the changes to the underlying dependencies impact the project, the overall project update might vary from a patch to a full major release.
 
 > [!IMPORTANT]
-> Don't modify the version numbers of dependencies in the **package.json** file manually. If you're using a lock file such as npm shrinkwrap, your manual changes to the package.json file will be ignored and the version numbers recorded in the lock files will be used instead which will lead to hard to track errors in your project.
+> Don't modify the version numbers of dependencies in the **package.json** file manually. If you're using a lock file such as npm shrinkwrap, your manual changes to the **package.json** file will be ignored and the version numbers recorded in the lock files will be used instead which will lead to hard to track errors in your project.
 
 #### Mind project structure changes