镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Align paths in traces #22575

Description

@piranna

When an exception is thrown or when using console.trace(), files paths are not aligned making it difficult to follow them at naked eye and specially to identify when it's one of your files, one internal module of if it's a file located inside node_modules folder:

UnhandledPromiseRejectionWarning: SyntaxError: Identifier 'body' has already been declared
     at Test.Runnable (/opt/app/node_modules/mocha/lib/runnable.js:36:25)
     at new Test (/opt/app/node_modules/mocha/lib/test.js:24:12)
     at context.it.context.specify (/opt/app/node_modules/mocha/lib/interfaces/bdd.js:85:18)
     at Function.context.it.only (/opt/app/node_modules/mocha/lib/interfaces/bdd.js:96:46)
     at Object.<anonymous> (/opt/app/src/modules/templates/template.spec.js:21:4)
     at Module._compile (internal/modules/cjs/loader.js:689:30)
     at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
     at Module.load (internal/modules/cjs/loader.js:599:32)
     at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
     at Function.Module._load (internal/modules/cjs/loader.js:530:3)
     at Module.require (internal/modules/cjs/loader.js:637:17)
     at require (internal/modules/cjs/helpers.js:20:18)
     at /opt/app/node_modules/mocha/lib/mocha.js:250:27
     at Array.forEach (<anonymous>)
     at Mocha.loadFiles (/opt/app/node_modules/mocha/lib/mocha.js:247:14)
     at Mocha.run (/opt/app/node_modules/mocha/lib/mocha.js:576:10)

Not sure if this is done at v8 level, but my proposal is to add spaces between the function name and the file paths so this last ones gets aligned between themselves to the longest one. In the previous trace, it would get like:

UnhandledPromiseRejectionWarning: SyntaxError: Identifier 'body' has already been declared
     at Test.Runnable                 (/opt/app/node_modules/mocha/lib/runnable.js:36:25)
     at new Test                      (/opt/app/node_modules/mocha/lib/test.js:24:12)
     at context.it.context.specify    (/opt/app/node_modules/mocha/lib/interfaces/bdd.js:85:18)
     at Function.context.it.only      (/opt/app/node_modules/mocha/lib/interfaces/bdd.js:96:46)
     at Object.<anonymous>            (/opt/app/src/modules/templates/template.spec.js:21:4)
     at Module._compile               (internal/modules/cjs/loader.js:689:30)
     at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
     at Module.load                   (internal/modules/cjs/loader.js:599:32)
     at tryModuleLoad                 (internal/modules/cjs/loader.js:538:12)
     at Function.Module._load         (internal/modules/cjs/loader.js:530:3)
     at Module.require                (internal/modules/cjs/loader.js:637:17)
     at require                       (internal/modules/cjs/helpers.js:20:18)
     at                                /opt/app/node_modules/mocha/lib/mocha.js:250:27
     at Array.forEach                 (<anonymous>)
     at Mocha.loadFiles               (/opt/app/node_modules/mocha/lib/mocha.js:247:14)
     at Mocha.run                     (/opt/app/node_modules/mocha/lib/mocha.js:576:10)

There would be problems if some code is parsing the trace output taking in consideration to be just only a space between the function name and the file path instead of several spaces, so this change would need to be in a major version, but anyway exception traces are not standard and such libs are very few and mostly for debuging purposses so their impact will be low, and is a small change that they would be easily added.

Activity

  1. addaleax commented on Sep 2, 2018

    @addaleax
    Member

    Not sure who to talk to here. @nodejs/v8 maybe? (edit: Sorry, I thought we had a TC39 team.)

  2. ryzokuken commented on Oct 27, 2018

    @ryzokuken
    Contributor

    @piranna @addaleax did we follow up on this? If not, I could start a discussion on the TC39 mailing list and CC you.

  3. piranna commented on Oct 28, 2018

    @piranna
    ContributorAuthor

    No, I didn't. Please start the discussion at TC39. Don't know if it's of their competence or v8 or Node.js, but I think if so TC39 would prefer instead to define a standard traces spec... At least this change would be a start for that :-)

  4. hashseed commented on Oct 28, 2018

    @hashseed
    Member

    You could easily achieve this by overriding Error.prepareStackTrace. I don't think we want to add the complexity for this in V8, especially since this is very bikesheddy.

  5. piranna commented on Oct 28, 2018

    @piranna
    ContributorAuthor

    Maybe would makes sense to implement this here in Node.js? Later it could be used as a proof-of-concept to implement it in other environments... Would you accept a pull-request for this?

  6. devsnek commented on Oct 29, 2018

    @devsnek
    Member

    @piranna i'm in the middle of rewriting our error stack decoration over in #23926. after that lands you could open a pr modifying the new stack decoration method we use.

    fair warning though, i don't think many people will be partial to the format you're proposing. most people don't have enough screen real-estate for it to be practical. this seems like its better suited to happen in userland with Error.prepareStackTrace, as hashseed said.

    There is also https://github.com/tc39/proposal-error-stacks

  7. piranna commented on May 21, 2019

    @piranna
    ContributorAuthor

    Now that #23926 has landed in master, can we start moving this? :-) Where should we start?

  8. srl295 commented on Jul 16, 2019

    @srl295
    Member

    @piranna just triaging here…

  9. piranna commented on Jul 16, 2019

    @piranna
    ContributorAuthor

    Done at tc39/proposal-error-stacks#30.

    • "you could open a pr modifying the new stack decoration method we use."

    Are you propossing that I implement it on Node.js code and create a pull-request with my changes?

  10. github-actions commented on Feb 28, 2022

    @github-actions
    Contributor

    There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

    For more information on how the project manages feature requests, please consult the feature request management document.

  11. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Feb 28, 2022
  12. piranna commented on Feb 28, 2022

    @piranna
    ContributorAuthor

    How can we move this forward? Maybe a PR implementing it here? I was asked to open one on tc-39 and got already stalled there...

  13. moved this from Pending Triage to Stale in Node.js feature requestson Feb 28, 2022
  14. 2 remaining items

  15. github-actions commented on Sep 1, 2022

    @github-actions
    Contributor

    There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

    For more information on how the project manages feature requests, please consult the feature request management document.

  16. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Sep 1, 2022
  17. piranna commented on Sep 1, 2022

    @piranna
    ContributorAuthor

    Any update on this? How can we move it forward?

  18. removed
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Sep 2, 2022
  19. github-actions commented on Mar 2, 2023

    @github-actions
    Contributor

    There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

    For more information on how the project manages feature requests, please consult the feature request management document.

  20. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Mar 2, 2023
  21. piranna commented on Mar 2, 2023

    @piranna
    ContributorAuthor

    Any update on this?

  22. removed
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Mar 3, 2023
  23. moved this from Stale to Pending Triage in Node.js feature requestson Apr 4, 2023
  24. github-actions commented on Aug 31, 2023

    @github-actions
    Contributor

    There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

    For more information on how the project manages feature requests, please consult the feature request management document.

  25. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Aug 31, 2023
  26. github-actions commented on Oct 1, 2023

    @github-actions
    Contributor

    There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

    For more information on how the project manages feature requests, please consult the feature request management document.

  27. piranna commented on Oct 1, 2023

    @piranna
    ContributorAuthor

    I still would like this to be considered, how can we proceed? Maybe I can do a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestIssues requesting new Node.js features.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions