Merge branch 'master' into turning-on-personal-access-token-blog

.local.env

@@ -0,0 +1 @@
+NX_DB_CACHE=true

docs/blog/2024-09-10-personal-access-tokens.md

@@ -56,10 +56,10 @@ read from the cache, but limit read/write access to core contributors.
 ![Personal access token settings in Nx Cloud workspace](/blog/images/2024-09-10/workspace-settings.avif)
 
 By default, a workspace that opts in to personal access tokens will allow anonymous users (users without a personal
-access token defined) read-only access. This can be changed to disallow access to the cache for anonymous users
+access token defined) read-write access. This can be changed to disallow access to the cache for anonymous users
 in your workspace settings.
 
-Users with personal access tokens will have read-only access to the cache. This can be changed to enable read-write
+Users with personal access tokens will also have read-write access to the cache. This can be changed to enable read-only
 access in the workspace settings.
 
 ## Converting existing workspaces to use personal access tokens
@@ -78,9 +78,9 @@ can [find more details in our docs](/ci/recipes/security/personal-access-tokens)
    `nx.json`,
    you'll need to provide that CI access token via the
    `NX_CLOUD_ACCESS_TOKEN` [environment variable](/ci/reference/env-vars#nxcloudaccesstoken).
-4. **_Optional_ Disable anonymous access** - By default, anyone without a personal access token will have read-only
+4. **_Recommended_ Disable anonymous access** - By default, anyone without a personal access token will have read-write
    access
-   to your cached artifacts. Once everyone has a personal access token defined, you can disable this anonymous access in
+   to your cached artifacts. You can disable this anonymous access in
    your Nx Cloud workspace settings.
 
 [Learn more about using personal access tokens](/ci/recipes/security/personal-access-tokens)

docs/nx-cloud/concepts/cache-security.md

@@ -24,9 +24,9 @@ In order to keep your cache secure, there are a few steps we recommend you take:
 
 ### Use Personal Access Tokens to Provide Fine-Grained Access Control for Local Development
 
-When you use a [personal access token](/ci/recipes/security/personal-access-tokens) to connect to Nx Cloud, you can control the level of access that your developers have to the cache after they authenticate by logging in. By default, all personal access tokens have read-only access to the cache. If you need to give a developer write access to the cache, you can do so in the workspace settings of the Nx Cloud UI.
+When you use a [personal access token](/ci/recipes/security/personal-access-tokens) to connect to Nx Cloud, you can control the level of access that your developers have to the cache after they authenticate by logging in. By default, all personal access tokens have read-write access to the cache. If you need to give a developer write access to the cache, you can do so in the workspace settings of the Nx Cloud UI.
 
-You can strengthen your workspace security further by revoking all access to the cache for unauthenticated users. This is done by changing the ID Access Level in your workspace settings. By default this is set to `read-only`, but you can change it to `none` to prevent all access.
+You can strengthen your workspace security further by revoking all access to the cache for unauthenticated users. This is done by changing the ID Access Level in your workspace settings. By default this is set to `read-write`, but you can change it to `read-only` to limit access or `none` to prevent all access.
 
 ### Avoid using CI Access Tokens in `nx.json`
 

docs/nx-cloud/recipes/personal-access-tokens.md

@@ -1,6 +1,6 @@
 # Nx Cloud and Personal Access Tokens
 
-From Nx 19.7 repositories are connected to Nx Cloud via a property in `nx.json` called `nxCloudId`. By default this value allows anyone who clones the repository `read-only` access to Nx Cloud features for that workspace. These permissions can be updated in the workspace settings. To disallow access to anonymous users or allow `read-write` access to known users it is required that all users provision their own personal access token. To do that they need to use [`npx nx-cloud login`](/ci/reference/nx-cloud-cli#npx-nxcloud-login).
+From Nx 19.7 repositories are connected to Nx Cloud via a property in `nx.json` called `nxCloudId`. By default this value allows anyone who clones the repository `read-write` access to Nx Cloud features for that workspace. These permissions can be updated in the workspace settings. To disallow access to anonymous users or allow `read-write` access to known users it is required that all users provision their own personal access token. To do that they need to use [`npx nx-cloud login`](/ci/reference/nx-cloud-cli#npx-nxcloud-login).
 
 {% callout type="warning" title="Personal Access Tokens require the `nxCloudId` field in `nx.json`" %}
 Ensure that you have the `nxCloudId` property in your `nx.json` file to connect to Nx Cloud with a Personal Access Token. If you have been using `nxCloudAccessToken`, you can convert it to `nxCloudId` by running [`npx nx-cloud convert-to-nx-cloud-id`](/ci/reference/nx-cloud-cli#npx-nxcloud-converttonxcloudid).
@@ -48,7 +48,17 @@ When you run [`npx nx-cloud login`](/ci/reference/nx-cloud-cli#npx-nxcloud-login
 
 ## Permissions
 
-By default all personal access tokens have `read-only` local access to Nx Cloud features for the workspace in which that user is a member. This can be updated to `read-write` in the workspace settings if required, although it is typical for local access to be restricted to `read-only`.
+There are two types of permissions that can be granted to users.
+
+### Workspace ID access level
+
+These are the permissions granted to users who clone your workspace, but have not authenticated with a personal access token via [`npx nx-cloud login`](/ci/reference/nx-cloud-cli#npx-nxcloud-login).
+By default, all users have `read-write` access to the workspace. This can be updated in the workspace settings to `read-only` or `none`.
+
+### Personal Access Token access level
+
+When a workspace member logs in with a personal access token after running [`npx nx-cloud login`](/ci/reference/nx-cloud-cli#npx-nxcloud-login) they are granted access to Nx Cloud features.
+By default all personal access tokens have `read-write` access to the remote cache. This can be updated to `read-only` in the workspace settings if required.
 
 ## Better Security
 

e2e/release/src/custom-registries.test.ts

@@ -17,14 +17,21 @@ describe('nx release - custom npm registries', () => {
   const verdaccioPort = 7191;
   const customRegistryUrl = `http://localhost:${verdaccioPort}`;
   const scope = 'scope';
+  let previousPackageManager: string;
 
   beforeAll(async () => {
+    previousPackageManager = process.env.SELECTED_PM;
+    // We are testing some more advanced scoped registry features that only npm has within this file
+    process.env.SELECTED_PM = 'npm';
     newProject({
       unsetProjectNameAndRootFormat: false,
       packages: ['@nx/js'],
     });
   }, 60000);
-  afterAll(() => cleanupProject());
+  afterAll(() => {
+    cleanupProject();
+    process.env.SELECTED_PM = previousPackageManager;
+  });
 
   it('should respect registry configuration for each package', async () => {
     updateJson<NxJsonConfiguration>('nx.json', (nxJson) => {

packages/js/src/executors/release-publish/release-publish.impl.ts

@@ -1,12 +1,17 @@
-import { ExecutorContext, readJsonFile } from '@nx/devkit';
+import {
+  detectPackageManager,
+  ExecutorContext,
+  readJsonFile,
+} from '@nx/devkit';
 import { execSync } from 'child_process';
 import { env as appendLocalEnv } from 'npm-run-path';
 import { join } from 'path';
+import { isLocallyLinkedPackageVersion } from '../../utils/is-locally-linked-package-version';
 import { parseRegistryOptions } from '../../utils/npm-config';
+import { extractNpmPublishJsonData } from './extract-npm-publish-json-data';
 import { logTar } from './log-tar';
 import { PublishExecutorSchema } from './schema';
 import chalk = require('chalk');
-import { extractNpmPublishJsonData } from './extract-npm-publish-json-data';
 
 const LARGE_BUFFER = 1024 * 1000000;
 
@@ -26,6 +31,7 @@ export default async function runExecutor(
   options: PublishExecutorSchema,
   context: ExecutorContext
 ) {
+  const pm = detectPackageManager();
   /**
    * We need to check both the env var and the option because the executor may have been triggered
    * indirectly via dependsOn, in which case the env var will be set, but the option will not.
@@ -44,6 +50,31 @@ export default async function runExecutor(
   const packageJson = readJsonFile(packageJsonPath);
   const packageName = packageJson.name;
 
+  /**
+   * pnpm supports dynamically updating locally linked packages during its packing phase, but other package managers do not.
+   * Therefore, protect the user from publishing invalid packages by checking if it contains local dependency protocols.
+   */
+  if (pm !== 'pnpm') {
+    const depTypes = ['dependencies', 'devDependencies', 'peerDependencies'];
+    for (const depType of depTypes) {
+      const deps = packageJson[depType];
+      if (deps) {
+        for (const depName in deps) {
+          if (isLocallyLinkedPackageVersion(deps[depName])) {
+            console.error(
+              `Error: Cannot publish package "${packageName}" because it contains a local dependency protocol in its "${depType}", and your package manager is ${pm}.
+
+Please update the local dependency on "${depName}" to be a valid semantic version (e.g. using \`nx release\`) before publishing, or switch to pnpm as a package manager, which supports dynamically replacing these protocols during publishing.`
+            );
+            return {
+              success: false,
+            };
+          }
+        }
+      }
+    }
+  }
+
   // If package and project name match, we can make log messages terser
   let packageTxt =
     packageName === context.projectName
@@ -88,7 +119,7 @@ export default async function runExecutor(
    * request with.
    *
    * Therefore, so as to not produce misleading output in dry around dist-tags being altered, we do not
-   * perform the npm view step, and just show npm publish's dry-run output.
+   * perform the npm view step, and just show npm/pnpm publish's dry-run output.
    */
   if (!isDryRun && !options.firstRelease) {
     const currentVersion = packageJson.version;
@@ -208,42 +239,45 @@ export default async function runExecutor(
 
   /**
    * NOTE: If this is ever changed away from running the command at the workspace root and pointing at the package root (e.g. back
-   * to running from the package root directly), then special attention should be paid to the fact that npm publish will nest its
+   * to running from the package root directly), then special attention should be paid to the fact that npm/pnpm publish will nest its
    * JSON output under the name of the package in that case (and it would need to be handled below).
    */
-  const npmPublishCommandSegments = [
-    `npm publish "${packageRoot}" --json --"${registryConfigKey}=${registry}" --tag=${tag}`,
+  const publishCommandSegments = [
+    pm === 'pnpm'
+      ? // Unlike npm, pnpm publish does not support a custom registryConfigKey option, and will error on uncommitted changes by default if --no-git-checks is not set
+        `pnpm publish "${packageRoot}" --json --registry="${registry}" --tag=${tag} --no-git-checks`
+      : `npm publish "${packageRoot}" --json --"${registryConfigKey}=${registry}" --tag=${tag}`,
   ];
 
   if (options.otp) {
-    npmPublishCommandSegments.push(`--otp=${options.otp}`);
+    publishCommandSegments.push(`--otp=${options.otp}`);
   }
 
   if (options.access) {
-    npmPublishCommandSegments.push(`--access=${options.access}`);
+    publishCommandSegments.push(`--access=${options.access}`);
   }
 
   if (isDryRun) {
-    npmPublishCommandSegments.push(`--dry-run`);
+    publishCommandSegments.push(`--dry-run`);
   }
 
   try {
-    const output = execSync(npmPublishCommandSegments.join(' '), {
+    const output = execSync(publishCommandSegments.join(' '), {
       maxBuffer: LARGE_BUFFER,
       env: processEnv(true),
       cwd: context.root,
       stdio: ['ignore', 'pipe', 'pipe'],
     });
 
     /**
-     * We cannot JSON.parse the output directly because if the user is using lifecycle scripts, npm will mix its publish output with the JSON output all on stdout.
+     * We cannot JSON.parse the output directly because if the user is using lifecycle scripts, npm/pnpm will mix its publish output with the JSON output all on stdout.
      * Additionally, we want to capture and show the lifecycle script outputs as beforeJsonData and afterJsonData and print them accordingly below.
      */
     const { beforeJsonData, jsonData, afterJsonData } =
       extractNpmPublishJsonData(output.toString());
     if (!jsonData) {
       console.error(
-        'The npm publish output data could not be extracted. Please report this issue on https://github.com/nrwl/nx'
+        `The ${pm} publish output data could not be extracted. Please report this issue on https://github.com/nrwl/nx`
       );
       return {
         success: false,
@@ -294,7 +328,7 @@ export default async function runExecutor(
     try {
       const stdoutData = JSON.parse(err.stdout?.toString() || '{}');
 
-      console.error('npm publish error:');
+      console.error(`${pm} publish error:`);
       if (stdoutData.error?.summary) {
         console.error(stdoutData.error.summary);
       }
@@ -303,7 +337,7 @@ export default async function runExecutor(
       }
 
       if (context.isVerbose) {
-        console.error('npm publish stdout:');
+        console.error(`${pm} publish stdout:`);
         console.error(JSON.stringify(stdoutData, null, 2));
       }
 
@@ -316,7 +350,7 @@ export default async function runExecutor(
       };
     } catch (err) {
       console.error(
-        'Something unexpected went wrong when processing the npm publish output\n',
+        `Something unexpected went wrong when processing the ${pm} publish output\n`,
         err
       );
       return {