[javascript] Create @seleniumhq/atoms npm package from TypeScript atoms

[AutomatedTester]

🔗 Related Issues

Builds on the Closure → TypeScript atom migrations (#17458 and siblings), which are already on trunk.

💥 What does this PR do?

Turns the three TypeScript atoms (get-attribute, find-elements, is-displayed) into real ES modules and compiles them down two independent paths from the same sources:

• IIFE path (language bindings) — ts_project with --module commonjs, then a new cjs-to-iife.js post-processor emits browser-injectable (function(){ … return fn; })(). Python, Ruby, Java and .NET consumers see byte-compatible output and are unchanged.
• npm path — ts_project with --module esnext, declaration, declarationMap and sourceMap into dist/, packaged as @seleniumhq/atoms with full .d.ts type declarations.

Both paths type-check the same .ts sources, so the published package and the injected atoms can't drift apart.

🔧 Implementation Notes

Atom sources

• Removed the outer IIFE from get-attribute.ts, find-elements.ts and is-displayed.ts; each now ends in export default <fn>.
• Added index.ts as the package entry point, re-exporting the three atoms as getAttribute, findElements and isDisplayed.

Build wiring (javascript/atoms/BUILD.bazel)

• Replaced the three js_run_binary + tsc --module none --outFile invocations with ts_project targets.
• Replaced the strip_trailing_semicolon binary with cjs_to_iife, which strips the CommonJS boilerplate tsc emits and wraps the remaining body in an IIFE returning the default export.
• Updated the three wrap-*-as-global.js scripts to parse CJS-compiled input rather than asserting the file starts with (function () {.
• Added atoms-npm-compiled (ts_project → dist/) and selenium-atoms-package (npm_package, publishable = True, tagged release-artifact).

One tsconfig per ts_project target
Each atom gets its own tsconfig-<atom>.json with a single-entry files list, rather than sharing one tsconfig-cjs.json across all three. A shared tsconfig makes several ts_project targets declare the same file as an input, which Bazel materialises concurrently into the same sandbox path — on Windows that races and fails with EPERM. Per-target configs give each action a disjoint input set. (tsconfig.json at the package root stays shared, because only atoms-npm-compiled uses it.)

Package metadata
javascript/atoms/package.json is promoted to @seleniumhq/atoms with exports entries for the package root and each individual atom.

✅ Verification

• bazel build //javascript/atoms:selenium-atoms-package //javascript/atoms:atoms-npm-compiled plus the three *-typescript-compiled targets — clean.
• bazel build //javascript/selenium-webdriver/lib/atoms:all //rb/lib/selenium/webdriver/atoms:all — clean; the generated IIFE output still ends in return get; })();, so the injection path is unchanged for bindings.

💡 Additional Considerations

• package.json currently declares "main": "./dist/index.cjs" and a "require" condition on every export, but the npm path only emits ESM .js + .d.ts — no .cjs is produced. Either the CJS conditions should be dropped (ESM-only package) or a second ts_project should emit the .cjs outputs before this is published. Flagging for a decision before release.
• The package version tracks the repo's nightly version string; it will need the usual release-tooling treatment the first time it ships.

🤖 AI assistance

• No substantial AI assistance used
• AI assisted (complete below)
  • Tool(s): Claude
  • What was generated: Templates
  • I reviewed all AI output and can explain the change

🔄 Types of changes

• New feature (non-breaking change which adds functionality)
• Cleanup (build wiring, formatting)

[AutomatedTester]

npm packaging: changes needed before @seleniumhq/atoms can be published

Notes for whoever picks this up next. All references are against 8146e8da. The IIFE path for the language bindings looks fine — everything below is specific to the new npm artifact.

Blockers

1. Every require condition points at a file that is never built

javascript/atoms/package.json declares "main": "./dist/index.cjs" plus a require condition on all four exports entries (., ./get-attribute, ./find-elements, ./is-displayed). There is no CJS compilation on the branch. The only tsconfigs present are:

• javascript/atoms/tsconfig.json — "module": "esnext", feeds :atoms-npm-compiled
• javascript/atoms/typescript/tsconfig-{get-attribute,find-elements,is-displayed}.json — per-atom, feed the IIFE path

The tsconfig-cjs.json named in the first commit message is not in the tree — the second commit (giving each ts_project its own tsconfig to fix the Windows TS5033 collision) replaced it. So dist/index.cjs and dist/typescript/*.cjs are never emitted, and require('@seleniumhq/atoms') fails at resolution time for anyone who installs this.

Two ways out:

• ESM-only (smaller, reasonable for a first release): drop "main" and all four require conditions. Add CJS later if a consumer asks.
• Dual: add a second ts_project with a CJS tsconfig writing .cjs outputs, and add it to npm_package.srcs.

2. No LICENSE/NOTICE in the published package

npm_package.srcs is ["package.json", ":atoms-npm-compiled"]. Apache-2.0 §4(a) requires a copy of the License to travel with the distribution, and npm publish won't synthesise one.

javascript/selenium-webdriver/BUILD.bazel already has the pattern, including the gotcha in the comment:

# npm_package does not pick up filegroup sources.
genrule(
    name = "license",
    srcs = ["//:license"],
    outs = ["LICENSE", "NOTICE"],
    cmd = "cp $(locations //:license) $(@D)",
)

Add the equivalent in javascript/atoms/BUILD.bazel and list ":license" in npm_package.srcs.

Correctness

3. The types condition must come first

In all four exports entries types is listed after import/require. Export condition order is significant — resolvers take the first match. Reorder so each entry reads types, then import (then require, if dual). As written it only resolves by .d.ts adjacency rather than by the condition, which @arethetypeswrong/cli flags and which breaks under some moduleResolution settings.

4. Source maps reference files that aren't in the tarball

tsconfig.json sets "declarationMap": true and "sourceMap": true, but "files": ["dist/"] and npm_package.srcs both exclude the .ts sources. Every emitted .d.ts.map / .js.map points at ../typescript/*.ts, which is not published, so go-to-definition and stack mapping land on nothing.

Either add the sources to the package, or set both options to false.

5. The version is hardcoded and won't track releases

package.json pins "version": "4.45.0-nightly202605121853", and the npm_package target has no version attribute, so nothing rewrites it. For comparison, javascript/selenium-webdriver/BUILD.bazel defines VERSION = "4.51.0-nightly202609302012" and passes version = VERSION to its npm_package. Mirror that so the release tooling drives the version — as written this would publish six minors behind trunk.

Worth a look

6. "type": "module" has blast radius beyond the npm package

javascript/atoms/package.json is the only package.json in that subtree, so adding "type": "module" makes all 41 .js files under javascript/atoms/ ES modules as far as Node's resolver is concerned. That includes the four js_binary entry points, each of which opens with require('node:fs'):

• typescript/cjs-to-iife.js
• typescript/wrap-as-global.js
• typescript/wrap-get-attribute-as-global.js
• typescript/wrap-find-elements-as-global.js

The Bazel build passes, so rules_js evidently isn't staging the manifest next to them in the runfiles tree — but running any of these directly (node javascript/atoms/typescript/cjs-to-iife.js in.js out.js) now fails with ReferenceError: require is not defined in ES module scope, and the build's correctness ends up resting on a rules_js staging detail rather than on anything declared.

If #1 lands as ESM-only, "type": "module" can be dropped entirely and the module format declared through exports alone, which removes the hazard.

7. Leftover devDependencies

"google-closure-deps": "^20230802.0.0" is inherited from when this manifest was the private selenium-atoms build-tools package. It won't reach consumers, but it's now misleading. Confirm nothing in the closure dep-graph targets resolves it through this manifest before removing.

8. No README — npm_package.srcs includes none, so the npm page will render empty for a brand-new scope.

Out of band — not a code change

The @seleniumhq npm scope is currently empty: https://registry.npmjs.org/-/v1/search?text=scope:seleniumhq returns total: 0, and @seleniumhq/atoms 404s. The scope needs creating under the project's npm org, and the release token needs publish rights on it, before any publish job can succeed. Worth claiming regardless of when this PR lands, since an unused scope is squattable.

Verification

Once the above is addressed:

bazel build //javascript/atoms:selenium-atoms-package
bazel test //javascript/atoms:closure-test      # confirm the IIFE path is unaffected

# against the built package directory
npx @arethetypeswrong/cli --pack .
npm pack --dry-run      # confirm LICENSE present; no stray .ts unless maps are kept
node -e "import('@seleniumhq/atoms').then(m => console.log(Object.keys(m)))"

That last one should print [ 'findElements', 'getAttribute', 'isDisplayed' ].