await import('package') behaves differently in serve vs. build results

[hirasso]

Describe the bug

This code:

const m = await import('mapbox-gl');

produces two differently structured objects in serve and build code bases.

Reproduction

I have this in my code:

// ...
const m = await import('mapbox-gl');
console.log(m)
// ...

When I have Vite running in serve mode, the log looks like this:

{
    "version": "2.5.1",
    "config": {
        "API_URL": "https://api.mapbox.com",
        "API_URL_REGEX": {},
        "EVENTS_URL": "https://events.mapbox.com/events/v2",
        "SESSION_PATH": "/map-sessions/v1",
        "FEEDBACK_URL": "https://apps.mapbox.com/feedback",
        "TILE_URL_VERSION": "v4",
        "RASTER_URL_PREFIX": "raster/v1",
        "REQUIRE_ACCESS_TOKEN": true,
        "ACCESS_TOKEN": null,
        "MAX_PARALLEL_IMAGE_REQUESTS": 16
    },
    "accessToken": null,
    "baseApiUrl": "https://api.mapbox.com",
    "workerCount": 2,
    "maxParallelImageRequests": 16,
    "workerUrl": "blob:https://vite-with-backend.test/cbee7a19-0b17-4b06-8d0d-eb41aab530c5",
    "workerClass": null
}

...but when I run vite build, logging the imported library results in this:

{
    "default": {
        "version": "2.5.1",
        "config": {
            "API_URL": "https://api.mapbox.com",
            "API_URL_REGEX": {},
            "EVENTS_URL": "https://events.mapbox.com/events/v2",
            "SESSION_PATH": "/map-sessions/v1",
            "FEEDBACK_URL": "https://apps.mapbox.com/feedback",
            "TILE_URL_VERSION": "v4",
            "RASTER_URL_PREFIX": "raster/v1",
            "REQUIRE_ACCESS_TOKEN": true,
            "ACCESS_TOKEN": null,
            "MAX_PARALLEL_IMAGE_REQUESTS": 16
        },
        "accessToken": null,
        "baseApiUrl": "https://api.mapbox.com",
        "workerCount": 2,
        "maxParallelImageRequests": 16,
        "workerUrl": "blob:https://vite-with-backend.test/ce1d9a78-33ee-4779-b35d-9259bd9b9109",
        "workerClass": null
    },
    "version": "2.5.1",
    "config": {
        "API_URL": "https://api.mapbox.com",
        "API_URL_REGEX": {},
        "EVENTS_URL": "https://events.mapbox.com/events/v2",
        "SESSION_PATH": "/map-sessions/v1",
        "FEEDBACK_URL": "https://apps.mapbox.com/feedback",
        "TILE_URL_VERSION": "v4",
        "RASTER_URL_PREFIX": "raster/v1",
        "REQUIRE_ACCESS_TOKEN": true,
        "ACCESS_TOKEN": null,
        "MAX_PARALLEL_IMAGE_REQUESTS": 16
    },
    "accessToken": null,
    "baseApiUrl": "https://api.mapbox.com",
    "workerCount": 2,
    "maxParallelImageRequests": 16,
    "workerUrl": "blob:https://vite-with-backend.test/ce1d9a78-33ee-4779-b35d-9259bd9b9109",
    "workerClass": null
}

...so the actual Mapbox module is tucked away under m.default after building my app. Could this be reworked so that the result would be the same in both scenarios? As a temporary workaround I am now always doing my async imports like this:

const {default: m} = await import('mapbox-gl');

But I thought I would report this anyways, since it feels like a bug to me. There already is a bug report about this #1168, but it apparently was closed without being resolved and I don't know how to re-open issues...

System Info

System:
    OS: macOS 11.6
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
    Memory: 496.04 MB / 16.00 GB
    Shell: 3.3.1 - /usr/local/bin/fish
  Binaries:
    Node: 14.18.1 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 8.1.1 - /usr/local/bin/npm
  Browsers:
    Brave Browser: 90.1.23.73
    Chrome: 95.0.4638.69
    Chrome Canary: 97.0.4687.2
    Firefox: 93.0
    Safari: 14.1.2
  npmPackages:
    vite: ^2.6.12 => 2.6.13

Used Package Manager

npm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[bluwy]

Looks similar to #6112

[sapphi-red]

@hemengke1997 #11198 (comment)
I'll reply here to make it visible.

so it's upstream rollup commonjs plugin issue?

This is related to rollup commonjs plugin.
Because this doesn't reproduce if build dep optimization is enabled.

// vite.config.js
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  build: {
    commonjsOptions: {
      include: []
    }
  },
  optimizeDeps: {
    disabled: false
  }
})

But I'm not sure whether it's a bug on Vite or plugin-commonjs.

Is there a temporary solution?...

You could use build dep optimization. I guess you can also workaround this by something like:

// @ts-expect-error there's a bug
const res = (_res.__esModule ? _res : _res.default) as typeof _res

[sapphi-red]

Maybe related: #6632

[hemengke1997]

@sapphi-red Thanks bro!

I found the docs about this then.
It helps me a lot. You too. Thanks

[Tanimodori]

Duplicate of #2139

[bluwy]

I can't reproduce the issue anymore. As linked above it might be already fixed the same way as #2139. The dev behaviour now aligns with prod (with the .default). Closing this as fixed.