Turbopack inappropriately compiling recursive function in Azure Maps

[kipprice-mbh]

Link to the code that reproduces this issue

https://github.com/kipprice-mbh/turbo-azure-maps/tree/main

To Reproduce

1. Set up an account with Azure Maps to get a subscription key
2. Set an environment var named AZURE_SUBSCRIPTION_KEY to the subscription key you received from Azure
3. Run pnpm dev and observe the map successfully loads
4. Run pnpm dev --turbo and observe the map fail to load

Current vs. Expected behavior

Currently, the react-azure-maps / azure-map-controls fail to load when using turbopack in a Next app (but work without issue when running without turbo). I'm submitting to the turbopack team because I've narrowed down at least some of the issue to an error that appears to be a mis-transpilation of the original recursive code.

The original Azure code is the following:

// azure-map-controls/dist/atlas-esm.js

function leastBadBreaks(lastLineBreak) {
  if (!lastLineBreak) {
    return [];
  }
  return leastBadBreaks(lastLineBreak.priorBreak).concat(lastLineBreak.index);
}

As you can see, if the argument is falsey at any point in the recursive call tree, it does not attempt to continue to call leastBadBreaks.

This is what turbopack compiles this code to:

return function e(t) {
    return ("TURBOPACK compile-time truthy", 1) ? e(t.priorBreak).concat(t.index) : ("TURBOPACK unreachable", undefined);

This no longer actual uses the truthiness of the argument, and instead always tries to get the value of t.priorBreak; this is crashing because the value is sometimes null. I would expect that arguments to recursive utilities are not determined at compile time.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:02:45 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T8112
  Available memory (MB): 24576
  Available CPU cores: 8
Binaries:
  Node: 18.19.1
  npm: 10.2.4
  Yarn: N/A
  pnpm: 9.0.5
Relevant Packages:
  next: 15.0.4 // Latest available version is detected (15.0.4).
  eslint-config-next: 15.0.4
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.2
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Runtime, Turbopack

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

I was unable to get a locally written dynamically-loaded element with a recursive utility to demonstrate the same behavior, but I also couldn't confirm whether turbo was actually compiling it as it does an external library.

Thank you for all of the work you do! Turbopack is great and I would love to be able to fullheartedly encourage my team to use in our codebase.