Eliminate/reduce custom require() shim

[pauldraper]

The current approach works by shimming require().

This is fragile, it's unclear if it even works with ES2015 modules (#228).

Is there a reason that rules_nodejs needs to inject runtime code for modern Node.js (6.3+). NODE_PATH and --preserve-symlinks (along with perhaps --preserve-symlinks-main) satisfies?

I believe Bazel's runfiles can be made compatible with native Node.js module resolution.

[alexeagle]

We now turn on --preserve-symlinks by default, so that's not the reason we have a custom module loader.
The problem is that there are several places where we load .js files, not just the node_modules directory provided as input. For example, there is .js that comes from output of a ts_library rule.

I think pubref/rules_node requires your nodejs_binary to be handed a single tree that does indeed work with native module resolution and uses $NODE_PATH - but then the user has to have nodejs_module rules between a JS-producer like ts_library and the nodejs_binary that consumes it, so that it can create a single tree.

[alexeagle]

We now have the //internal/linker which means there's no need for custom require / module resolver

The new rollup_bundle rule in packages/rollup uses the linker and can do rollup plugins and has no custom require.

We'll use this tracking bug to port more rules to use the linker and make the custom require logic guarded by a flag, which will eventually have its default flipped and later removed.

[alexeagle]

update here: any rules loaded from generated @npm//some-package:index.bzl now use the --nobazel_patch_module_resolver flag, so they don't have a custom require() shim. Still working in #1440 and #1445 to roll this out in all generated targets. Then we'll finally need to roll out in all first-party authored nodejs_binary and nodejs_test rules. We're stuck in the mixed state for 1.0 but I think this is a major item for 2.0

[github-actions]

This issue was automatically closed because it went two weeks without a reply since it was labeled "Can Close?"

[alexeagle]

#2125 is the current issue for this - the patched module resolver should be opt-in