Just thinking out loud here... .assuming one or more of these results in a non-trivial expansion, it might make sense to create npm modules (perhaps under the @ruby2js scope/namespace?). A filter might not be needed, but perhaps it could do whatever transformation is needed (if any) and insert the necessary import statements.

Definitely like the @ruby2js namespace idea, and an automatic import sounds interesting as well!

An example of automatic imports, try going to https://whimsy.apache.org/ruby2js/node/esm and entering the following

system "echo hi"

The resulting javascript will be:

import child_process from "child_process";
child_process.execSync("echo hi", {stdio: "inherit"})

Very cool!

As luck would have it, npm already has a SecureRandom.alphanumeric implementation in base62-random. I've committed experimental support for this (without docs) in 6e11f31

Disjointed thoughts:

• the code to add CJS requires and ESM imports isn't very DRY. That likely should be refactored by having all code generate s(:import) nodes, and having the converter for import do the right thing; cjs and ``esmcould be an option, and thenode` and `esm` filters could influence the default for this option, probably with the default ending up being esm UNLESS the node filter is used AND the esm filter is NOT used.
• While this an similar filters can be individually included, there may be value in having an umbrella stdlib filter that combines all of relevant filters.
• There may be value in tracking the imports that are found and having the object that Ruby2js.convert returns have a method that returns this list.
• while base64_random is relatively unlikely to be collision with variable names in the converted script, it isn't impossible for it to be a collision. Over time, as more modules are created, this chance goes up. Perhaps a convention like adding a trailing $ to such variable names might be worth exploring, as such would never be a valid Ruby identifier.

I like all of those ideas, and I would love to have a more official subsystem for imports, not only on the tracking output side as you mentioned, but I could also envision setting up some autoimports. Not necessarily something full-blown ala Zeitwerk, but maybe a situation where the converter is passed a hash of classes/methods -> paths and then when it encounters that class or method used in a file it makes sure that gets imported from elsewhere in the source tree. For example I write a lot of files where I always have to import three things from one particular file, and if that was just assumed dynamically it would clean things up very nicely. It's the kind of stuff that gives an even more Ruby-esque feel.

but maybe a situation where the converter is passed a hash of classes/methods -> paths and then when it encounters that class or method used in a file it makes sure that gets imported from elsewhere in the source tree

Something like dacda5b perhaps?

Just added a new active_functions filter along with a supporting NPM package (tiny, zero-dependency) where we can hang a few of the ActiveSupport-inspired functions. Starting out with blank?, present?, and presence

JS working example: https://codepen.io/jaredcwhite/pen/MWjvYgb