Esm: Error on default export

[JSteunou]

Add issues with 3.2.0 just tested 3.2.1 but import from module (like import things from ./index.js) does not work

index.js file has named export before default export dunno if that relevant.

[dnalborczyk]

hey @JSteunou

what error message are you getting? is index.js a commonjs or es6 module? could you create a reduced repro repository, or provide some repro steps?

[jamessouth]

I think I am having an issue with this too on 3.2.1. I used yarn create esm so I have the generated index and main files, with index requiring main. When I use export { name } in main, it works, but when I change it to export default name, I get an error from my consuming file (which requires index) that the export is not a function. Elsewhere I successfully use export default name when the importing file uses import instead of require.

[jamessouth]

I made an issue repo here.

[jdalton]

Hi @jamessouth!

I cannot reproduce this issue with esm v3.2.1 on Node 6.16.0 or Node 11.9.0.

[ianrosedev]

I had the same issue and it looked to be with internal/modules/cjs/loader.js.
Running npm i again fixed it for me.

[jdalton]

This is likely related to the regression in v3.2.0 (#721) which was patched in v3.2.1.

[jamessouth]

I have node 10.15.1 the latest LTS. When I comment out the named export and run the default in the issue repo I shared, I get an error but I don't get it when I comment out the default export and run the named. Can you repro on 10.15.1?

[JSteunou]

@jdalton I will test again and provide more intel as soon as I have some bandwith but I had not the same error message between 3.2.0 & 3.2.1 so I am pretty sure it is not the same issue.

[JSteunou]

All cases with nodejs 8.15.0 & npm 6.7.0

3.2.0

With 3.2.0 I had an error at runtime because

import * as Foo from './foo'

gives an empty Foo object module where foo.js has a lot of name export

3.2.1

With 3.2.1 I have this error before runtime

file:///opt/project/src/models/user.js:1
SyntaxError: The requested module 'file:///opt/project/src/models/index.js' does not provide an export named 'default'

models/index.js

import {initSequelize} from '@common/src/models'

// user is the 1st imported model
import {User} from './user'
// plus others models

const models = [User, /* + others models */]

export const sequelize = initSequelize(models)
export default sequelize.models

models/users.js

import {getConfig} from '@common/src/utils'
import {DataTypes, Model} from 'sequelize'
import models from './index'

export class User {
  // ... more code
  // some using models.OtherModel
}

3.0.84

No errors

3.1.4

Same error than in 3.2.0

[dnalborczyk]

@jamessouth I could not reproduce it either with your repo. could you compare and see if you are taking any different steps than below?

nvs use 10.15.1  # use latest node LTS
git clone https://github.com/jamessouth/esm-issue-repo
cd esm-issue-repo
yarn
node .
node index.js
node -r esm .
node -r esm index.js

everything above runs fine without any errors. consumer.js is not referenced anywhere btw, is that correct?

[dnalborczyk]

@jamessouth never mind, just noticed that you were likely trying to run node consumer.js. would be good to highlight that somewhere next time 😉

anyhow, in order to import and run a default function in commonjs exported from an es6 module, you would do:

const log = require("./index").default
log()

or:

const { default: log } = require("./index")
log()

[dnalborczyk]

one more thing, to avoid confusion.

this:

const log = require("./index");
log();

was working and introduced with esm v3.2.0, but was recognized as not a good idea and subsequently reverted in esm v3.2.1.

[dnalborczyk]

@JSteunou you have a lot of missing pieces in the above example/repro as well as user specific and likely unrelated code, which could change the outcome in any direction. you might want to reduce it to something specific. otherwise it's nearly impossible to see what the problem or the solution would be.

[JSteunou]

@dnalborczyk I updated the example a little more. All missing pieces can be mocked as empty object or noop function

Can you point what's missing ?

[manniL]

@dnalborczyk

Having the following test.js file:

export default class Test {}

Test.something = 'ok'

will throw with [email protected]

node -r esm test.js
file:///home/..../test.js:1
ReferenceError: Test is not defined
at Object. (file:///home/.../test.js:3:1)
at Generator.next ()

but not with [email protected] nor [email protected]

[dnalborczyk]

@JSteunou I'll have a look.

@manniL thanks! this is likely a regression, and I believe unrelated to this issue.

[manniL]

@dnalborczyk I thought it might be because it's also related to default exports.

Should I open a new issue? ☺️

[dnalborczyk]

@manniL yes please, that would be great! thank you!

[dnalborczyk]

@JSteunou sorry, I tried a couple combinations. no error. you might wanna create a simple repository for reproduction. that would be very helpful.

[jamessouth]

yes @dnalborczyk clone it, cd to the folder, yarn and node consumer.js. Thank you!😊

adding .default to the require worked!😁

So: if you change the js files to mjs, you don't need esm, but then you need to use the --experimental-modules flag and you can't use a package that doesn't export an es6 module. With esm you can use both es6 and cjs exports in the same project and the default resolution above is how you es6 export a single default rather than a single named export. Thank you again!😃

[jdalton]

@JSteunou I'm closing this for now. Feel free to post a simplified repro and we'll dig in.

[JSteunou]

@dnalborczyk I tracked it down and it is a combination of mocha + esm >= 3.1 that causes the issue

Repro https://github.com/JSteunou/esm-issue-722

@jdalton I d appreciate you did not close this issue this fast. I'm on a different timezone and with a limited bandwidth, this adds ton of delay to our interaction. This doesnot make this issue not real and I think I have shown some effort to help you help me with it, like in https://github.com/standard-things/esm/issues/722#issuecomment-461021607

[dnalborczyk]

thank you for the repro @JSteunou !

@jdalton I d appreciate you did not close this issue this fast. I'm on a different timezone and with a limited bandwidth, this add ton of delay to our interaction. This does make this issue not real and I think I have shown some effort to help you help me with it, like in #722 (comment)

don't take it personal. it's just @jdalton 's way of handling and keeping track of the issues. just keeps the issue tracker clean (compare: https://github.com/lodash/lodash). closing issues fairly fast can be somewhat off-putting for some, I understand, but hey, I take that over anything when you realize how quick issues are REALLY being addressed.

@JSteunou I'm closing this for now. Feel free to post a simplified repro and we'll dig in.

pretty much says that your issue isn't being ignored at all.

[jdalton]

@JSteunou Than you for the repo!

I have fixed the issue locally. The issue is that when using mocha -r esm the esm loader is in a side-loaded state. By that I mean that esm is loaded by mocha require()ing it. That means that subsequent require()s will load ES modules. The issue was we weren't processing the parse-only pass in those cases. During the parse pass for ESM we finalize their namespace objects. So when it requested the default, since it was not finalized, it thought there was no default export.

Update:

Patch https://github.com/standard-things/esm/commit/4480fa84c2e7966f51a454c7497c557c3dce49b6; Test https://github.com/standard-things/esm/commit/fa9c19f74714c267d5ebc5232e27e7ea855bef9b;