Import the correct ./typeof.js helper in @babel/runtime

[exb]

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

Context

When a helper depends on another helper which is not explicitly imported (see code snippet below), the babel-plugin-transform-runtime will inject the helper at the top but it will not inject it in the proper module format version.

Let's take the possibleConstructorReturn as an example. The helper itself does not "explicitly" depend on typeof:

babel/packages/babel-helpers/src/helpers.ts

Lines 618 to 630 in 89cab43

	helpers.possibleConstructorReturn = helper("7.0.0-beta.0")`
	import assertThisInitialized from "assertThisInitialized";
	export default function _possibleConstructorReturn(self, call) {
	if (call && (typeof call === "object" || typeof call === "function")) {
	return call;
	} else if (call !== void 0) {
	throw new TypeError("Derived constructors may only return object or undefined");
	}
	return assertThisInitialized(self);
	}
	`;

When building possibleConstructorReturn (build-dist#247) the babel-plugin-transform-runtime plugin will run over it and inject the unimported typeof at the very top as follows:

+ import _typeof from "@babel/runtime/helpers/typeof";
import assertThisInitialized from "./assertThisInitialized.js";

The issue is that the injected module format is CJS instead of being picked up by the context. The desired output should be the following:

- import _typeof from "@babel/runtime/helpers/typeof";
+ import _typeof from "./typeof.js";
import assertThisInitialized from "./assertThisInitialized.js";

The solution
To fix the issue I updated the adjustImportPath function to rewrite the imports generated from the babel-plugin-transform-runtime as relative path imports.

I realize that this PR is just patching the problem rather than making the transform runtime plugin import the proper module format in the first place. Doing that, however, would require us to do some rethinking of the build-dist file, which considering the issue was marked as "good first issue", I deemed it was out of scope. Let me know if I should proceed otherwise.

Testing
Guidance on testing the build-dist file is appreciated.
Updated: Commited the helper generated code to avoid regressions.

[nicolo-ribaudo]

You can "test" this (i.e. prevent regressions) by unignoring possibleConstructorReturn.js from .gitignore, and commit the helper generated code. We already do that, for example, with toArray.

[JLHwung]

The import "@babel/runtime/helpers/typeof" is generated by @babel/plugin-transform-typeof-symbol which runs before the buildRuntimeRewritePlugin plugin. In this case I will prefer just convert "@babel/runtime/helpers/typeof" to "./typeof": So this plugin does not accidentally support "@babel/runtime/helpers/another-helper".

[nicolo-ribaudo]

If there are injected imports for other helpers, wouldn't we want to transform them too?

[JLHwung]

Yes they should.

Not related to this PR: I realized that the generated helper will target to browserlists's default in Babel 8 since we didn't supply a target in the build-dist. I guess it's fine to bump the targets but we should convey that in the changelog.

[exb]

Thanks for the feedback, I updated the PR with your suggestions :)

[nicolo-ribaudo]

Awesome, thanks!