How to show errors in vscode or other editor when macro is throwing MacroError or buildCodeFrameError?

[AmitDigga]

• babel-plugin-macros version: ^3.0.1
• node version: v12.16.3
• npm version: 6.14.4

Relevant code or config

function macroHandler({ references, state, babel }: MacroParams) {
  const { types: t } = babel;
  const { Hello = []} = references;
  Hello.forEach((refPath) => {
    throw new MacroError("Not Working");
  });
}

What you did: I tried this macro on another create-react-app.

What happened:

This macro error was only available when app was started or build.

// this is not the exact code. I used my Macro in App render function.
import {Hello} from 'my-macro/lib/hello-macro.macro';
Hello("World") 

Problem description: Error was not shown on vscode. The macro I am building is a little bit complex so I am asserting errors at the early stages.

1. Is there any way to show the error with line-numbers or columns in vscode or other IDEs?
2. What is the use of MacroError? Can this be used in to do that?
3. I tried buildCodeFrameError which gave some context where error is happening. Not in the IDE, but at time of compilation. So which one should be used?

Suggested solution: None

[conartist6]

Well the only way for the IDE to report an error would be for the IDE to know enough to try running the macro, which really would mean looking up the babel config and attempting to transpile the file with babel. I don't see that vscode has any plugins that do this, and so I assume other editors don't have such a thing either.

But! As it so happens, I've been working on something that could fulfill your use case: the macrome build system. It's not done yet, but an initial version will be ready soon. The idea is that it watches the files in your repo and then does certain actions based on rules. E.g. you could set it up so that *.with-macros.js (or whatever naming convention you prefer) would be fed through babel-plugin-macros and the file with macros transpiled would then *.js, right alongside the original. When the configured action fails the system is smart enough to write a file that just statically throws an error. The advantage to this is that it would solve your problem in every IDE and editor, and your favored tooling for detecting compile-time errors can let you know that something is wrong, whether it be Typescript or eslint-plugin-import.

[conartist6]

In case @kentcdodds is reading, this is why I'm putting in the effort to help support macros. I hope the build system will help them be useful for more things. It was also born of my belief that transpiled code is your product: it should be checked into source control, it should be available for static analysis, and it should be possible to understand it (even if it's a bit verbose). I think this will gain a lot more traction as we start using es6 as a transpilation target instead of es5.

[kentcdodds]

Sounds interesting! Thank you for your support and work!