Using const VCF = require('@gmod/vcf') doesn't give constructor

[cmdcolin]

$ cat index.js
const VCF = require('@gmod/vcf')

console.log(VCF)
$ node index.js
{ parseBreakend: [Function: parseBreakend], default: [Function: VCF] }

may have been a regression from exporting parseBreakend, but technically that was a major version bump

may need to update docs to

const VCF = require('@gmod/vcf').default

other note:

even if you change type:module in package.json to try to use es6 imports in a nodejs environment, we don't get the right result

$ cat package.json
{
  "name": "test",
  "version": "1.0.0",
  "main": "index.js",
  "author": "Colin",
  "license": "MIT",
  "type": "module",
  "dependencies": {
    "@gmod/vcf": "^5.0.2"
  }
}
$ cat index.js
import VCF from '@gmod/vcf'

console.log(VCF)
$ node index.js
{ parseBreakend: [Function: parseBreakend], default: [Function: VCF] }

could suggest a need to add a "module" field to @gmod/vcf's package.json

[cmdcolin]

I think I can confirm that using @gmod/vcf@4 gives the right thing (@5, the current major version, gives multiple results)

[cmdcolin]

now accesses @gmod/vcf.default

[gaitat]

This issue shouldn't be closed. In version 5.0.10

After doing import VCF from '@gmod/vcf'

I need to do new VCF.default() in order to get a constructor back.

[cmdcolin]

hi @gaitat. it may depend on the platform (e.g. bundler like webpack, or runtime like nodejs) you are using. you will not need the .default if your "platform" recognizes the package.json "module" field which is admittedly not a standardized field, but it is something we have used to allow ESM-style usages, but if your platform doesn't recogize it, you will indeed need the .default

we can consider revisiting and/or documenting this in the readme more. it is related to growing pains of commonjs vs ESM stuff, i hesitate to make our modules pure-ESM because i have run into problems with it but it may be worth it one day

if you want to make a new issue for it feel free

[cmdcolin]

made #102 to try to track