nrwl / nx

Smart Monorepos Β· Fast CI
https://nx.dev
MIT License
23.53k stars 2.35k forks source link

Feature Request: nx format:check should provide a workaround for Prettier not supporting format diffing #4159

Open jacopolanzoni opened 3 years ago

jacopolanzoni commented 3 years ago

UPDATE FROM NX TEAM (2024-05-17)

Please read: https://github.com/nrwl/nx/issues/4159#issuecomment-2118165264


Description

As nx format:check shows which files fail the format check but not what is actually wrong in them, I would love if the --verbose option could actually add that information. At the moment, unless I am doing something wrong, nx format:check --verbose has the same output as nx format:check.

Motivation

The command would give more information about what is actually wrong in the file format.

Suggested Implementation

I would love if the --verbose option could actually add that information.

Alternate Implementations

As an alternative, I would like even only to see either the line where the check fails, or maybe the broken rule.

github-actions[bot] commented 3 years ago

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. If we missed this issue please reply to keep it active. Thanks for being a part of the Nx community! πŸ™

konrad-garus commented 3 years ago

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.

TCModus commented 2 years ago

My entire team is complaining about this, going to have to remove my formatting check from pre-commit hook because it is just confusing everyone. The --verbose flag should be at minimum spitting out the same output of the format:write command which at least shows the command crawling through the project directories doing the formatting.

FYI for others with this issue it seems like you can run prettier using npm and get the output from running the prettier command directly instead of through Nx.

Alspaladin commented 2 years ago

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

eprokofev commented 2 years ago

I don't understand "stale" logic as well. My pipeline also failed at this step without any reason. Verbose is not informative at all.

xaphod commented 2 years ago

Yeah, reopen this issue - verbose is broken

KlausNie commented 2 years ago

Same here

konnic commented 2 years ago

Just ran into the same issue, would like to see this issue being reopened...

konnic commented 2 years ago

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.

TCModus commented 2 years ago

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: @.***>

StephenStrickland commented 2 years ago

nx format:check --verbose is still broken

edit: It also appears that if you provide the base and head params the command exits with 1 but doesn't print the files that failed formatting.

e.g.

nx format:check --base=main --head=HEAD
# exit code 0 

nx format:check --base=main --head=HEAD --verbose
# exit code 0 

nx format:check
 >  NX   Affected criteria defaulted to --base=main --head=HEAD
/path/to/failed/file
# exit code 1

nx format:check --verbose
 >  NX   Affected criteria defaulted to --base=main --head=HEAD
/path/to/failed/file
# exit code 1

Unless there's some way to turn off the "warning" logging that nx has select a base and head, we can't even pipe the results of nx format:check and parse the results.

shawnmclean commented 2 years ago

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

savvyshell commented 2 years ago

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

savvyshell commented 2 years ago
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.

MaxKless commented 2 years ago

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.

nhhockeyplayer commented 2 years ago

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.

pujux commented 2 years ago

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

Clean-Cole commented 2 years ago

Our team is having the same issue.

kekiel commented 2 years ago

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

dgesteves commented 2 years ago

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

StefanGreffenius commented 2 years ago

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

PayBas commented 2 years ago

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.

gerald-kalafut commented 2 years ago

bump This is affecting my work flow as well. Please add descriptive text that identifies what is being flagged.

amogower commented 2 years ago

+1 for providing info on failed check please πŸ™

kodeine commented 2 years ago

bump, please this is needed. πŸ™

meisterveda commented 2 years ago

Still verbose not working correctly

JPedroSMFerreira commented 1 year ago

$ 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Γ‘!

brumargues commented 1 year ago

@JPedroSMFerreira, it worked like a gem!

But --verbose still needs a fix.

Thank you!

exsesx commented 1 year ago

@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.

algoflows commented 1 year ago

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

theonetheycallneo commented 1 year ago

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

timothylombrana commented 1 year ago

I want to bump this as it's still an issue with the lastest.

pujux commented 1 year ago

you would think a team working on a project this size and importance would recognize such an issue that has been complained about for more than 2 years now... pretty disappointing to not even get any answer from the team on this...

I already tried my luck with fixing this the first time I came here, didn't work well as you see. But I think me having to come here again is a pretty good sign that I should just try again, since nobody will take on this issue apparently.

kodeine commented 1 year ago

Maybe its time to open a new ticket?

72gm commented 1 year ago

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

jozef-ivanic-simplicity commented 1 year ago

the same over here. thank you for ignoring us!

algoflows commented 1 year ago

Same here, had tonnes of ballach on my last project related to this. Surprised they're ignoring it so hard.

On Mon, 27 Mar 2023, 15:10 Jozef Ivanič, @.***> wrote:

the same over here. thank you for ignoring us!

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

HenrikTusz commented 1 year ago

Same here, failing in ci but working locally.

timonmasberg commented 1 year ago

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.

marc-wilson commented 1 year ago

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?

ak274 commented 1 year ago

I'm also facing this issue in gitlab ci npx nx format:check fails without telling what's wrong! Wasted many hours and then come here to look into this issue

tomavic commented 1 year ago

I had same issue too and it's really confusing. Is it main or master :/

My ci.yml

name: Publish Libraries
'on':
  push:
    branches:
      - main
  pull_request:

jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo βœ…
        uses: actions/checkout@v2
      - name: Install Dependencies πŸ”§
        run: |
          if [ -e yarn.lock ]; then
          yarn install --frozen-lockfile
          elif [ -e package-lock.json ]; then
          npm ci
          else
          npm i
          fi
      - name: Pretty code πŸ’„
        run: npx nx format:check
      - name: Lint ♻️
        run: npx nx affected -t lint
      - name: Build πŸ“¦
        run: npx nx affected -t build
      - name: Test πŸ§ͺ
        run: npx nx affected -t test --ci --code-coverage
      - name: Release πŸš€
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: npx nx affected -t release

and it fails at the linting stage, saying

Run npx nx affected -t lint
  npx nx affected -t lint
  shell: /usr/bin/bash -e {0}

 >  NX   Affected criteria defaulted to --base=master --head=HEAD

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>...]'
nx affected

Run target for affected projects

Run command using --base=[SHA1] (affected by the committed, uncommitted and untracked changes):
      --base  Base of the current branch (usually main)  [string]

or using --base=[SHA1] --head=[SHA[2](https://github.com/tomavic/enigma-nx-angular/actions/runs/4710392822/jobs/8353993527?pr=2#step:5:2)] (affected by the committed changes):
      --base  Base of the current branch (usually main)  [string]
      --head  Latest commit of the current branch (usually HEAD)  [string]
pujux commented 1 year ago

@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

tomavic commented 1 year ago

@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 βœ”οΈ

zhumeisongsong commented 1 year ago

Same here, failing in ci but working locally.

chief-austinc commented 1 year ago

+1

chaunceyau commented 1 year ago

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

Oliviu27 commented 1 year ago

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

abhi40308 commented 1 year ago

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.

lukket commented 1 year ago

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 πŸ™ˆ.