[Question] How to handle @babel/runtime

I am looking for advice on how to move forward with a project I am working on.

The issue I am having is how @babel/plugin-transform-runtime inserts require() statements to @babel/runtime like @babel/runtime/helpers/interopRequireDefault. Basically, unless the user has @babel/runtime installed in their project, running babel will fail.

I understand that to make it work, it’s as easy as installing @babel/runtime in the project. However, what I am developing is a plugin which is going to be doing transformations on some of the user’s source files so that they can be consumed. I am trying to make this plugin’s usage as straightforward as possible, and requiring the user to install new dependencies that they aren’t even going to use is just bad DX.

There are a couple of options that are apparent to me so far:

1. Additional documentation to say, “hey, if you’re using yarn2, you might need to install this other package. Don’t worry, you won’t need it, but the plugin MIGHT”
   • This is definitely not foolproof, because not everybody reads documentation. And then there’s plenty of frustration when things don’t work how they should, then research (maybe) to figure out why… or it just gets abandoned.
2. Hard fail in the plugin if that particular package is not installed, maybe with a helpful error message.

Both of these options are rather poor, IMO. I would very much prefer to install @babel/runtime in the plugin, and have it be available to the user’s project automatically. Can’t seem to get that to work, however.

What would be great is if there were a way to define the resolution location of some kind of transitive dependency like this one, but maybe I’m just missing the real solution.

I would be grateful for any advice.

---

You can find an example reproduction here: https://github.com/Js-Brecht/babel-transform-runtime-issue

The folder source is basically the “user’s project”, while register is the “plugin”. In source, you can run yarn start, and it will show the error. Obviously, running everything from the context of that project, it would make sense to install @babel/runtime.

Running yarn exec will kind of replicate the process I’m looking for. Having a dependency execute @babel/register, and then execute one of the user’s scripts. I do have @babel/runtime installed in the “plugin”, but that doesn’t help any.

Running yarn exec2 will replicate another type of processing that will be done. There will be a runtime path for the plugin that will do ahead-of-time transpiling using babel, so that the scripts can be executed normally later on. Same problems.

[Js-Brecht]

Btw, using that option worked perfectly.

[Js-Brecht]

I’m not sure peer dependencies would be the fix - if I understand correctly in your case you’d have Foo depends on MyTranspiler, and you’d want Foo to access Runtime without listing it inside its dependencies - somehow accessing it only because MyTranspiler happens to depend on it. Peer dependencies can only go the other way, with Foo giving access to something to MyTranspiler.

Thank you for the explanation. It makes more sense to me now.

I was considering writing a babel plugin that I could hook into the transformation from the transpiler plugin’s context to resolve certain paths as they are encountered. Kind of like babel-plugin-module-resolver but… not exactly.

I think this issue is fixed if you set the absoluteRuntime flag with plugin-transform-runtime (which is basically what you mentioned by manually resolving the path)

I think this should actually be perfect. These files are transpiled specific to the runtime, so using absolute paths should definitely work.

I have been rather disappointed in the quality of the babel documentation to date, and it rarely (if ever) answers my questions. So, I admit, I didn’t read the documentation thoroughly for that plugin. Thank you very much for the direction 🙏.

---

After a brief examination of the code for that option, I’m pretty certain it will work. I am closing this issue now. Thanks again!