Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: edge case with some undefined default exports? #87

Open
richardeschloss opened this issue Oct 19, 2022 · 3 comments
Open

Question: edge case with some undefined default exports? #87

richardeschloss opened this issue Oct 19, 2022 · 3 comments

Comments

@richardeschloss
Copy link

richardeschloss commented Oct 19, 2022

I have a library that is attempting to import from socket.io. Here is the related issue: https://github.com/richardeschloss/nuxt-socket-io/issues/278

When I attempt to import and the run nuxt3, I encounter the following error:

"Cannot start nuxt: Cannot destructure property 'Server' of '_engineIo.default' as it is undefined"
at node_modules/engine.io/wrapper.mjs:3:9
at jiti (node_modules/jiti/dist/jiti.js:1:247502)

Inside of wrapper.mjs, the first line seems to be the issue because ./build/engine.io.js does not seem to export a default:

import lib from "./build/engine.io.js"; // released, broken, gets installed with socket.io 4.5.3
// import * as lib from "./build/engine.io.js"; // works

My question is, I'm able to run the following successfully; i.e., inside wrapper, I can console.log(lib):

node node_modules/engine.io/wrapper.mjs

But when I run nuxi dev, I encounter the error. My follow up question is how does my command succeed when there appears to be no default? How can I get Nuxt to overcome this missing default?

Fwiw, I'm on Node 16 (LTS), nuxt3.0.0-rc.12-27768618.05fd222, my nuxt config is pretty minimal, and package type set to "module" in package.json

@richardeschloss
Copy link
Author

Some more context: The wrapper I'm referencing follows the conventions listed here: https://nodejs.org/docs/latest-v16.x/api/packages.html#approach-1-use-an-es-module-wrapper

// ./node_modules/pkg/package.json
{
  "type": "module",
  "exports": {
    "import": "./wrapper.mjs",
    "require": "./index.cjs"
  }
}
// ./node_modules/pkg/index.cjs
exports.name = 'value';  // <-- In the CJS file, there's no "default" export but... (see below)

// ./node_modules/pkg/wrapper.mjs
import cjsModule from './index.cjs'; // NodeJS imports the CJS module wholly without issue; equivalent to `import * as cjsModule from './index.cjs';
export const name = cjsModule.name;

@Thy3634
Copy link

Thy3634 commented Oct 24, 2022

I think the question is:
jiti modify A.cjs, and A require B.cjs. And A has been converted to import pkg from B

B.cjs exports = { a: ..., b: ... }, If it converted, B.mjs would be export default {a: ..., b: ...}.
So far, it's OK.

But actually B has a B.mjs:

import lib from './B.js' // this B.js has not been converted
export const { a: ..., b: ...} = lib

@richardeschloss
Copy link
Author

richardeschloss commented Oct 24, 2022

Should the conversion be something like?:

import * as pkg from "B"
const dfltExport = pkg.default || pkg // This way we always get a default in .mjs
export dfltExport

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants