[turbopack] dynamic import with path alias not working

[stefanprobst]

Link to the code that reproduces this issue

https://github.com/stefanprobst/issue-turbopack-imports

To Reproduce

1. clone reproduction repo, install deps
2. npm run dev
3. open http://localhost:3000/ and see error message

Current vs. Expected behavior

i have the following dynamic imports, which work with webpack, but not with turbopack:

export async function i18n(locale: string) {
  /** This works with both turbopack and webpack. */
  // const messages = await import(`../messages/${locale}.json`)

  /** This works with webpack, but fails with turbopack. */
  const messages = await import(`@/messages/${locale}.json`)

  return messages
}

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #202401311935 SMP PREEMPT_DYNAMIC Thu Feb  1 00:46:47 UTC 2024
  Available memory (MB): 31403
  Available CPU cores: 16
Binaries:
  Node: 20.11.1
  npm: 10.2.4
  Yarn: 1.22.19
  pnpm: 8.15.4
Relevant Packages:
  next: 14.2.0-canary.26 // Latest available version is detected (14.2.0-canary.26).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.2
Next.js Config:
  output: N/A

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

Turbopack (--turbo)

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

next dev (local)

Additional context

reopening https://github.com/vercel/next.js/issues/61279 which was closed as a duplicate of https://github.com/vercel/next.js/issues/56531, which is marked as fixed - however the problem in this issue is not yet fixed.

_PACK-2801

[EliasVal]

I am having the same issue, it seems to have been fixed sometime during the 14.2.0 canary, but Turbopack for windows on the canary is borked for now.

[EliasVal]

@anaedwards73 Hello! I didn't mean that the package is not available now, it's just that Turbopack is currently still in preview and instability & incompatibility are expected for now. If you must use the path alias, you should probably stick to Webpack until this issue is fixed.

[EliasVal]

As far as I'm aware, you can't use --turbo with next build so it wouldn't do much :P If --turbo makes development easier/faster for you with minimal refactoring, you can freely use it in my opinion. But if it is too tedious to use, stick to Webpack for now.

I'm using turbo for development at work, and it works just fine :)

[alexanderbnelson]

This is still an issue as of 14.3.0-canary.29

I have a repo that replicates the problem here: https://github.com/alexanderbnelson/dynamic-import-turbo

[waltershewmake]

@sokra, it looks like you previously resolved #56531 back in February with vercel/turbo#7153, but the issue has resurfaced. Can you offer any insight into the problem?

[pixelchutes]

Thank you for filing this issue. Currently looking to enable --turbo for local development as well -- using Next.js 14.2.3 (turbo) -- but appear to be running into the same issue when using dynamic imports + path alias.

@waltershewmake Regarding #56531, it appears it was reverted as part of: https://github.com/vercel/turbo/pull/7153

@ForsakenHarmony @sokra Perhaps one of you can confirm if this is the case? I double checked https://areweturboyet.com but didn't notice anything specifically failing around this issue.

[derek-rein]

I'm using turbopack with @blueprintjs/datetime2 which uses dynamic imports for datefns The following traceback is with

    "date-fns": "^3.6.0",
    "next": "14.3.0-canary.36",

The error message

Module not found
  27 |                 case 0:
  28 |                     _b.trys.push([0, 2, , 3]);
> 29 |                     return [4 /*yield*/, import(
     |                                          ^^^^^^^
> 30 |                         /* webpackChunkName: "date-fns-locale-[request]" */
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 31 |                         "date-fns/locale/".concat(localeCode, "/index.js"))];
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  32 |                 case 1:
  33 |                     localeModule = _b.sent();
  34 |                     return [2 /*return*/, localeModule.default];

The file in question from Blueprint

import { __awaiter, __generator } from "tslib";
import * as React from "react";
import { Utils } from "@blueprintjs/core";
/**
 * Lazy-loads a date-fns locale for use in a datetime class component.
 */
export function loadDateFnsLocale(localeCode) {
    return __awaiter(this, void 0, void 0, function () {
        var localeModule, _a;
        return __generator(this, function (_b) {
            switch (_b.label) {
                case 0:
                    _b.trys.push([0, 2, , 3]);
                    return [4 /*yield*/, import(
                        /* webpackChunkName: "date-fns-locale-[request]" */
                        "date-fns/locale/".concat(localeCode, "/index.js"))];
                case 1:
                    localeModule = _b.sent();
                    return [2 /*return*/, localeModule.default];
                case 2:
                    _a = _b.sent();
                    if (!Utils.isNodeEnv("production")) {
                        console.error("[Blueprint] Could not load \"".concat(localeCode, "\" date-fns locale, please check that this locale code is supported: https://github.com/date-fns/date-fns/tree/main/src/locale"));
                    }
                    return [2 /*return*/, undefined];
                case 3: return [2 /*return*/];
            }
        });
    });
}
/**
 * Lazy-loads a date-fns locale for use in a datetime function component.
 */
export function useDateFnsLocale(localeOrCode, dateFnsLocaleLoader) {
    if (dateFnsLocaleLoader === void 0) { dateFnsLocaleLoader = loadDateFnsLocale; }
    // make sure to set the locale correctly on first render if it is available
    var _a = React.useState(typeof localeOrCode === "object" ? localeOrCode : undefined), locale = _a[0], setLocale = _a[1];
    React.useEffect(function () {
        setLocale(function (prevLocale) {
            if (typeof localeOrCode === "string") {
                dateFnsLocaleLoader(localeOrCode).then(setLocale);
                // keep the current locale for now, it will be updated async
                return prevLocale;
            }
            else {
                return localeOrCode;
            }
        });
    }, [dateFnsLocaleLoader, localeOrCode]);
    return locale;
}
//# sourceMappingURL=dateFnsLocaleUtils.js.map

[RexGalicie]

Faced same issue, v Next.js 14.3.0-canary.38 (turbo)

[RexGalicie]

Why some one marked my comment as spam, it is not spam at all. I have same issues when uses dynamic imports include i18n, and NX. Instead marking it as spam provide clear ETA to resolve it Cheers

[gurkerl83]

Experience the same issue. It would be really helpful if someone of the developer team can confirm that dynamic imports are currently not supported with in dev mode with turbopack enabled.

https://github.com/vercel/turbo/pull/7397

Thx!

[timneutkens]

@RexGalicie the comment you posted is to the extent of "same issue". These are automatically hidden by GitHub because they're not useful, if you want to raise that you're also running into the issue but you don't have any new context you can add a thumbs up (👍) at the top -- providing that it still happens is not new context as the issue is still open --

I.e.:

So to be clear we did not mark it, this happened automatically.

@gurkerl83 the issue is synced into our tracker, which means you can assume that it's an issue. Dynamic imports are supported, the thing that is not supported yet is adding path aliases and then those path aliases applying for dynamically generated paths. If you take the example application and change @/ with just ../ it works: https://codesandbox.io/p/github/stefanprobst/issue-turbopack-imports/csb-dr5fvq/draft/pedantic-benji?file=%2Flib%2Fi18n.ts%3A7%2C1

TLDR: import(`../messages/${locale}.json`) works, while an aliases path like import(`@/messages/${locale}.json`) does not.

The alias case is something that still has to be implemented.

@derek-rein your case would be useful to have as a separate issue as it's unrelated to the reported issue of having path aliases, instead that library has some quite strange output code that we'll have to add special handling for in Turbopack in order to collect the concat calls as dynamic paths.