Hide internal @babel/core functions in config errors

[nicolo-ribaudo]

Q	A
Fixed Issues?	Closes #11540
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

This PR introduces some logic to hide @babel/core internals in error stack traces for errors coming from outside @babel/core itself (for example, coming from config files or plugins/presets): @babel/core introduces a lot of frames (and all duplicated, because of how we use gensync), which are not really useful.

Unexpected errors thrown inside @babel/core itself still have the complete stack trace, because they are bugs and we need debug info.

If you want to see the old stack traces, you can replace const SUPPORTED = !!Error.captureStackTrace; with const SUPPORTED = false; and run the tests.

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/52794/

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 686dfa8:

Sandbox	Source
hopeful-cache-0dr69	Configuration
sad-hooks-tow69	Configuration
thirsty-goodall-2d6el	Issue #11540

[liuxingbaoyu]

This PR looks great! The current stack provides little useful information.

[nicolo-ribaudo]

@liuxingbaoyu Since you use windows, when you have time could you clone this PR, run yarn jest babel-core/test/errors-stacks and see why the tests are not throwing when they should? 🙏

[liuxingbaoyu]

This is the same as #14671 (comment), by the way I also found a typo there although it works fine.😂

[liuxingbaoyu]

To be honest, the CI exception from the fork repo scares me.😅
This is extremely strange, I often have similar problems too in my personal repo, but almost none in the main repo.😕

[nicolo-ribaudo]

Thank you! 😄

[liuxingbaoyu]

Maybe there is some lint rule to make it a normal string, but in this PR I think it's ok.🤫

[ehoogeveen-medweb]

There's @typescript-eslint/quotes, which can be configured with allowTemplateLiterals: false to avoid unnecessary template literals (despite the name, it does not forbid all usage of template literals). To be compatible with Prettier, avoidEscape: true must also be set (even if you extend eslint-config-prettier, individual rule configurations take precedence).

[JLHwung]

The type casting can be avoided if we parameterize the function's input and output.

export function beginHiddenCallStack<T, A extends any[], R>(
  fn: (this: T, ...args: A) => R,
) {
  if (!SUPPORTED) return fn;

  return Object.defineProperty(
    function (this: T, ...args: A) {
      setupPrepareStackTrace();
      return fn.apply(this, args);
    },
    "name",
    { value: STOP_HIDNG },
  );
}

[nicolo-ribaudo]

We still need to type cast somewhere, because the functions that we receive in the config have type Function which is not compatible with the "explicit" function types. However, I moved them to the config validation logic so that the "internals" are properly typed.

[JLHwung]

Nit: Can you restrict the typing here? It seems to me status can only be "hiding" | "showing" | "unknown".

[JLHwung]

Suggested change

	* expected error thrown by c(), it's shown call stack would have been "h, e, f".
	* expected error thrown by c(), its shown call stack would have been "h, e, f".

May extend the example a bit, for example, what will be the shown call stack if we called injcectVirtualStackFrame(error, "h") and injcectVirtualStackFrame(error, "i")?