Identifier '$Completions' has already been declared about import-in-the-middle HOT 10 CLOSED

This can be reproduced with:

a.mjs

export const foo = "a"

b.mjs

export const foo = "b"

index.mjs

export * from './a.mjs'
export * from './b.mjs'

But we seem to be playing whack-a-mole with the ludicrous number of permutations ESM provides for exporting entities.

The Map isn't working to de-duplicate because the keys are derived from:

Buffer.from(modFile, 'hex') + Date.now() + randomBytes(4).toString('hex')

from import-in-the-middle.

Throwing is ok in some circumstances, but we'd rather not have any cases where registering the hook causes code to throw where it didn't before.

from import-in-the-middle.

Got to this error after tackling #59, for what it is worth.

from import-in-the-middle.

#53 was meant to solve this sort of issue. But we seem to be playing whack-a-mole with the ludicrous number of permutations ESM provides for exporting entities. I am quite open to suggestions here.

from import-in-the-middle.

It's worth noting this is failing at a higher level now in 4.40.1 of openai. However that release broke cjs exports, and someone logged this issue

npm i [email protected]
node --loader=import-in-the-middle/hook.mjs --input-type=module -e "import OpenAI from 'openai'; const a = new OpenAI();"

    let $OpenAI = $171467968826591576f6c.OpenAI
        ^

SyntaxError: Identifier '$OpenAI' has already been declared
    at ModuleLoader.moduleStrategy (node:internal/modules/esm/translators:167:18)
    at callTranslator (node:internal/modules/esm/loader:285:14)
    at ModuleLoader.moduleProvider (node:internal/modules/esm/loader:291:30)

from import-in-the-middle.

I'm trying to setup Sentry for Node.js (type: module) with the following guide https://docs.sentry.io/platforms/javascript/guides/express/install/esm/ wich recommends the --import command line option to import the instrument.js/.mjs file and can't at the moment due to this issue. I keep getting the Identifier '$Completions' has already been declared error. It seems they are using this package in their SDK.

from import-in-the-middle.

@timfish, looks promising!

from import-in-the-middle.

@timfish what is the expected "export" of:

index.mjs

export * from './a.mjs'
export * from './b.mjs'

Genuinely, I do not know what the export should be. Both a.mjs and b.mjs export a single foo symbol. So which one wins, b?

from import-in-the-middle.

Ok so I just tested Node without the loader and the behaviour depends on the import:

With:
a.mjs

export const foo = "a"

b.mjs

export const foo = "b"

duplicate.mjs

export * from './a.mjs'
export * from './b.mjs'

The following:

import * as e from './duplciate.mjs'

console.log('exports', e);

Results in:

exports [Module: null prototype] {  }

And this

import { foo } from './duplciate.mjs'

console.log('foo', foo);

Results in an error

import { foo } from '../fixtures/duplicate.mjs'
         ^^^
SyntaxError: The requested module '../fixtures/duplicate.mjs' contains conflicting star exports for name 'foo'
    at ModuleJob._instantiate (node:internal/modules/esm/module_job:131:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:213:5)
    at async ModuleLoader.import (node:internal/modules/esm/loader:316:24)
    at async loadESM (node:internal/process/esm_loader:34:7)
    at async handleMainPromise (node:internal/modules/run_main:66:12)

So I guess we need to mirror this behaviour?

from import-in-the-middle.

That makes sense for the presented replication. I think we should definitely throw an error in this case since it is clearly an unresolvable situation. However, we need to figure out how to replicate the allowed graph that the OpenAI module seems to be making use of, and determine a way to handle it appropriately.

The whack-a-mole game continues 🤣

from import-in-the-middle.