nx: nx format:check --verbose should actually show what is wrong with a file

It’s like a slap in the face without ever even telling you why. Imagine a compiler telling you “Error, GFY, period”.

Please add this.

If it helps anyone, running nx format:write solved issue for me. Nevertheless, it would be nice if the --verbose flag provided some extra info.

Why it’s closed? My project is failing on nx format:check without any message besides the error Command failed with exit code 1. and --verbose adds nothing to it

This is passing locally and failing in CI for me. Both running on same node and npm versions.

Can somebody deal with this please… it’s a massive pain in the backside… fine locally but failing in CI with no information whatsoever…

$8.6M in seed funding at the end of last year so you should have the resources

why is this closed as completed if it’s still a problem?

Yeah, reopen this issue - verbose is broken

How has this not been addressed , it’s running fine locally, failing in CI with no information.

What’s happening with this lol, two years and nothing!

Our team is having the same issue.

Same here

So I mentioned Miroslav Jonas on Twitter to try and see if the team has taken notice on the issue and here is his reply: https://x.com/meeroslav/status/1706345582242001064?s=46&t=ZnrURlqYmjZQZciRM14ZDA

we might be getting a solution soon 🥳

Why hasn’t this issue been formally addressed yet? this should be fixed

Same here, the fact that it’s been almost 2.5 years without a fix to such a obvious issue is sad

@JPedroSMFerreira, it worked like a gem!

But --verbose still needs a fix.

Thank you!

This issue is about the format:check command. It’s not a solution if we have to change the command, which is completely changing the logic, by the way.

We could forward args to the prettier command, or you could find a way to print your message before the format:check execution.

It would’ve been nicer to have a solution developed by the NX team to make it more flexible. I had a complaint from my team that they couldn’t figure out why they could not commit their changes because of the output of the format command. We got used to it, though, and adjusted our processes.

$ nx format:write

NX Affected criteria defaulted to --base=develop --head=HEAD

libs\common\ui-sales-components\src\lib.… 477ms libs\common\ui-sales-components\src\lib\save… 183ms angular.json 236ms nx.json 12ms tsconfig.base.json 49ms

Et voilá!

I am still having this issue with my CI any solution?

+1 for showing what is wrong with the file(s)

@vsavkin, this issue was raised nearly 3 years ago. It has the most 👍 and ❤️ reactions of any issue for this project, and has about 46 subscribers.

nx format:check is essentially unusable in it’s current state, yet it’s still included in the Nx docs.

Can you please give an update on whether this issue will ever be addressed, or mark nx format:check and nx format:write as deprecated and provide an alternative (e.g. npx prettier --check . and npx prettier --write .).

We parse our build logs to collect data on issues. The output of nx format:check is less than useless and is impossible to parse since there is nothing identifying the error, except the exit code. I would at least expect some kind of line (even without the --verbose flag) like:

NX/Prettier format check error(s) for file(s):
<the file list>

But as others have mentioned, actually showing some verbose output is desperately needed.

Same issue here, we are missing the detailed error output of prettier. Would be great if you could reopen the issue.

init-commands: |
  npx nx-cloud record -- npx prettier --write .
  npx nx-cloud record -- npx nx format:write
  npx nx-cloud record -- npx prettier --check .
  npx nx-cloud record -- npx nx format:check

I added this to my actions.yml file and it seems to do the trick. Rather than rely on nx format:check, I hand it over to prettier since it’s tied to my eslint configuration and I’d imagine nx format:check is using part of that anyways. I have it auto format with prettier followed by nx format:write just to be safe before checking with both prettier and nx format check.

It’s probably not necessary to use both but just to still make sure NX is some-what happy, I wanted to use their format checker.

Seems to work now, hope we can get a proper solution for this in the future. At least with npx prettier --check, we get a bit more of a verbose output than format:check’s tragic lack of insight in its output.

Hey everyone,

We’ve found it challenging to determine when nx format:check fails because it merely lists out files without any additional context about the formatting issues. To make this clearer for our team, I created a bash script. This script not only runs nx format:check, but it also explicitly highlights the files with formatting errors and recommends running npx nx format:write to address these issues.

Here is an example of it in action:

Here’s the script:

pretty-format-check.sh

#!/bin/bash

# ANSI color codes
RED='\033[0;31m'
GREEN='\033[0;32m'
CYAN='\033[0;36m'
NC='\033[0m'
SEPARATOR="----------------------------------------"

# Run nx pretty-format-check and capture the output
output=$(nx format:check 2>&1)

# Capture the exit status
result=$?

# Check if the command failed
if [ $result -ne 0 ]; then
    echo -e "${RED}$SEPARATOR"
    echo -e "Error: Formatting check failed"
    echo -e "$SEPARATOR${NC}"
    echo -e "Files with formatting issues:\n$output\n"
    echo -e "${CYAN}Please run 'npx nx format:write' to fix formatting issues."
    exit $result
fi

echo -e "${GREEN}Formatting check passed successfully.${NC}"

To use this script, save it as pretty-format-check.sh and make sure it’s executable. You can do this with:

chmod +x pretty-format-check.sh

Also, I’ve added it as an npm script in package.json for convenience:

"scripts": {
    "pretty-format-check": "./pretty-format-check.sh"
}

Now, you can simply run npm run pretty-format-check to execute the script.

Hope this helps make formatting checks a breeze!

+1 for providing info on failed check please 🙏

Please correct me if I’m wrong but it seems like all nx does is execute prettier under the hood anyways: https://github.com/nrwl/nx/blob/969aa32659f6918cb0eeeba6b02d6485659dbdd2/packages/nx/src/command-line/format.ts#L201

So if we want more verbose output, this will probably be the place to implement it.

Try adding angular.json, nx.json, and tsconfig.base.json to your prettier ignore file and that should work. I noticed on every change prettier was touching angular.json file even when it wasn’t changed, once I ignored those files I was getting proper behavior running nx format:check without the verbose flag (we actually no longer run check and our pre-commit hooks run nx format:write which has been working fine after ignoring the above files).

TCModus

On Tue, Feb 22, 2022, 11:33 AM konnic @.***> wrote:

If it helps anyone, running nx format:write solved issue for me.

— Reply to this email directly, view it on GitHub https://github.com/nrwl/nx/issues/4159#issuecomment-1047984058, or unsubscribe https://github.com/notifications/unsubscribe-auth/APEHQMLCL653STVWERMXE43U4O3DZANCNFSM4UD77B6A . You are receiving this because you commented.Message ID: @.***>

@tomavic you are encountering a different issue. you need to add fetch-depth to your actions/checkout action to have all history you need for nx.

from https://github.com/actions/checkout#readme

# Number of commits to fetch. 0 indicates all history for all branches and tags.
# Default: 1
fetch-depth: ''

also have a look at: https://github.com/nrwl/nx-set-shas

@JPedroSMFerreira, it worked like a gem!

But --verbose still needs a fix.

Thank you!

I added a message on their discord if everyone here replies to that maybe they’ll notice something? 🤷🏻‍♂️

I’ve blasted up there youtube threads with links too this issue, maybe the team will finally address it.

I really wonder how this command made it into production. The documentation actually says nothing about what the command really does, instead it’s written somewhere else. And the output is just a bad joke 🙈.

If your format check is failing on CI but working locally, you might have some files which are being generated in CI, which might not be formatted properly. You can add those files to .prettierignore. In my case, npm ci was generating mockServiceWorker.js, which was failing on lint check. This got resolved after adding it to .prettierignore.

Workflow:

name: lint frontend

on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          ref: ${{ github.event.pull_request.head.ref }}
          fetch-depth: 0
      - uses: actions/setup-node@v3
        with:
          node-version: '16'
      - run: yarn install --immutable
      # Note: nx format:check does the `nx affected` check automatically, so it needs a ref to compare against
      - run: git fetch --no-tags --prune --depth=5 origin main
      - run: yarn nx format:check --base=main --head=HEAD
      - run: yarn eslint:check

.prettierignore

# Add files here to ignore them from prettier formatting

/dist
/coverage
/.vscode
/node_modules
/tools/msw/mockServiceWorker.js

If your format check is failing on CI but working locally

You can verify this as not being a problem with nx by replacing nx format:check and just run prettier directly on CI yarn prettier -c . should still fail with the same output.

opened an MR to address this here: https://github.com/nrwl/nx/issues/4159, open to feedback

Same here, failing in ci but working locally.

@tomavic you are encountering a different issue. you need to add fetch-depth to your actions/checkout action to have all history you need for nx.

from https://github.com/actions/checkout#readme

# Number of commits to fetch. 0 indicates all history for all branches and tags.
# Default: 1
fetch-depth: ''

also have a look at: https://github.com/nrwl/nx-set-shas

Thanks @pujux That is a really different issue and I’ve fixed it using the correct usage of actions/checkout@v2 and https://github.com/nrwl/nx-set-shas ✔️

I am confused as well. I am evaluating Nx and am playing around with their Azure DevOps example here.

The documentation offers this snippet:

trigger:
  - main
pr:
  - main

variables:
  CI: 'true'
  ${{ if eq(variables['Build.Reason'], 'PullRequest') }}:
    NX_BRANCH: $(System.PullRequest.PullRequestNumber)
    TARGET_BRANCH: $[replace(variables['System.PullRequest.TargetBranch'],'refs/heads/','origin/')]
    BASE_SHA: $(git merge-base $(TARGET_BRANCH) HEAD)
  ${{ if ne(variables['Build.Reason'], 'PullRequest') }}:
    NX_BRANCH: $(Build.SourceBranchName)
    BASE_SHA: $(git rev-parse HEAD~1)
  HEAD_SHA: $(git rev-parse HEAD)

jobs:
  - job: main
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - script: npm ci

      - script: npx nx format:check

      - script: npx nx affected --base=$(BASE_SHA) -t lint --parallel=3
      - script: npx nx affected --base=$(BASE_SHA) -t test --parallel=3 --configuration=ci
      - script: npx nx affected --base=$(BASE_SHA) -t build --parallel=3

But, I get an error when it runs npx nx format:check

fatal: ambiguous argument ‘master’: unknown revision or path not in the working tree.

Using a suggestion in another comment (changing it from check to write), I get the same error in the logs, but it doesn’t return an exit code of 1 and allows my pipeline to continue on to the next build task.

Full build logs

with npx nx format:check

Starting: CmdLine
==============================================================================
Task         : Command line
Description  : Run a command line script using Bash on Linux and macOS and cmd.exe on Windows
Version      : 2.212.0
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/command-line
==============================================================================
Generating script.
Script contents:
npx nx format:check
========================== Starting Command Output ===========================
/usr/bin/bash --noprofile --norc /home/vsts/work/_temp/38edf7c3-b384-4c31-bdc1-dee7fbdc928f.sh
fatal: ambiguous argument 'master': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
apps/api-e2e/jest.config.ts
apps/api-e2e/src/api/api.spec.ts
apps/api-e2e/src/support/global-setup.ts
apps/api-e2e/src/support/test-setup.ts
apps/api/jest.config.ts
apps/api/src/app/app.controller.spec.ts
apps/api/src/app/app.controller.ts
apps/api/src/app/app.module.ts
apps/api/src/app/app.service.spec.ts
apps/api/src/app/app.service.ts
apps/api/src/main.ts
apps/api/webpack.config.js
apps/app/src/app/app.component.ts
jest.config.ts
jest.preset.js
##[error]Bash exited with code '1'.
Finishing: CmdLine

with npx nx format:write

Starting: CmdLine
==============================================================================
Task         : Command line
Description  : Run a command line script using Bash on Linux and macOS and cmd.exe on Windows
Version      : 2.212.0
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/command-line
==============================================================================
Generating script.
Script contents:
npx nx format:write
========================== Starting Command Output ===========================
/usr/bin/bash --noprofile --norc /home/vsts/work/_temp/27daa746-95fc-41d1-9993-5b0509e5e408.sh
fatal: ambiguous argument 'master': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
apps/api-e2e/jest.config.ts
apps/api-e2e/src/api/api.spec.ts
apps/api-e2e/src/support/global-setup.ts
apps/api-e2e/src/support/test-setup.ts
apps/api/jest.config.ts
apps/api/src/app/app.controller.spec.ts
apps/api/src/app/app.controller.ts
apps/api/src/app/app.module.ts
apps/api/src/app/app.service.spec.ts
apps/api/src/app/app.service.ts
apps/api/src/main.ts
apps/api/webpack.config.js
apps/app/src/app/app.component.ts
jest.config.ts
jest.preset.js
tsconfig.base.json
Finishing: CmdLine

I created a documentation issue (#16241) for this initially, but it sounds like this command may be having troubles in a pipeline?

We experienced the same issue. This is probably related to https://github.com/prettier/prettier/issues/6885

When we investigated this issue, we ran prettier write and checked the diff. It was not locally detected with nx format or with prettier for the whole project, but failed in the CI.

I also noticed that VSCode’s auto-save doesn’t match nx format:write, so we were continuously getting this issue.

angular.json, nx.json, and tsconfig.base.json

That worked for me thanks friend

finally got nxcloud builds in flight

npmjs.org held me down for whole month in a user account debilitation locked out from their case logic creating users for emails that they dont even validate… ditched npmjs for github registry and I think this is the trend. sorry npmjs its been real.

nxcloud rocks… integrated to everything

do not release bad stuff into the public domain its going to get engineers very upset who are live in the field operating prod instances and thus far Nx and GitHub has been great. Wish I could say same for yarn, npm, webpack and other flanking entities. I know I wont sign my name to anything buggy. npmjs was last straw.