feat: expose api in the browser console

[shren207]

close #1186

the existing bundler configuration was already well-structured, so the implementation went very smoothly.

Open Questions

1. Improving the console guide text

The current console guide text does not tell users that they can call APIs via _. or __.. I tried adding a hint like:

But the result looked little bit verbose, so I didn’t include it in the commit. 😅

Any suggestions for a cleaner, more discoverable console text are welcome!

2. Managing the BUNDLE_PATH constant

Since both es-toolkit and es-toolkit/compat bundle paths needed to be referenced from two separate files, I extracted the paths into a shared file at /configs/bundlePath.ts and exported them from there.

I couldn’t find any existing code that clearly shows how global constants are typically managed in this project, so I went with this approach. If there’s a preferred or recommended pattern for managing constants in this project, I’d appreciate any guidance!

3. Exposing both es-toolkit and es-toolkit/compat in the console

Is it necessary to expose both es-toolkit and es-toolkit/compat on the global object, or should we expose only one of them?

4. Alias names _ and __

Are _ and __ intuitive choices for the global aliases? If there are clearer or more conventional names, I’d love to hear them.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
es-toolkit	🛑 Canceled (Inspect)			Jun 7, 2025 6:12am

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.51%. Comparing base (e57ee91) to head (598b760).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1191   +/-   ##
=======================================
  Coverage   99.51%   99.51%           
=======================================
  Files         457      457           
  Lines        4339     4339           
  Branches     1286     1286           
=======================================
  Hits         4318     4318           
  Misses         21       21           

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dayongkr]

I haven’t reviewed it in detail yet, but I’d like to decouple it from the package build as much as possible. Something like:

<script type="module">
import * as es from "https://cdn.jsdelivr.net/npm/es-toolkit@latest/+esm";
window.es = es;
</script>

This way, we can load the latest build directly in the browser. What do you think about going in this direction?

[shren207]

@dayongkr That sounds like a much better approach! I found that /docs/.vitepress/shared.mts already contains code for loading external JS scripts in a way that’s compatible with VitePress. With that as a reference, I implemented your suggested approach — and it worked exactly as intended! Thank you for the simple yet excellent idea!