Handle `export default` in import data files

[jessevdp]

I just ran into this issue where all the added data would show up under a single document (with a single ID) in MongoDB. After about 30 minutes of tinkering around, trying stuff, and digging through the source code—I noticed how I exported my data using export default instead of export = [].

Why would export default result in this module thinking that I want to add an array as single document? export = [] doesn't really seem like a pattern many libs use/require?

‼️ Wrong way

export default [
  { name: "My First Item" },
  { name: "My Second Item" },
  { name: "My Third Item" },
  { name: "My Last Item" }
];

✅ Right way

export = [
  { name: "My First Item" },
  { name: "My Second Item" },
  { name: "My Third Item" },
  { name: "My Last Item" }
];

Suggestion

Maybe it's safe to assume that when the user exports an array, they want it to be imported as separate documents in their database?

Overal very useful tool, saves me a bunch of boilerplate code. 😄

[pkosiec]

Hi @jessevdp,

Thanks for the issue. Let me answer your questions first.

Why would export default result in this module thinking that I want to add an array as single document?

Basically, Mongo Seeding traverses directories in given location and requires all files defined there (using require()).
When requiring a given file, where there is export default defined, then we receive object with single default property. So, for example requiring a single file with simple content export default [] will result in the following object: { default: [] }.

export = [] doesn't really seem like a pattern many libs use/require?

It is used quite widely in TypeScript community - it's an alternative to the module.exports = approach from Node.js. From what I've observed, export default is common pattern for front-end apps, like React one.

Anyway, I agree with you - Mongo Seeding could simply detect a case when someone used export default and then get the content from default property in the required object. It will be easy to implement it - will do it in next version!

[jessevdp]

Ah I see, most of my JS knowledge comes from the frontend world indeed.

Once you get it, that this is the pattern, it’s not a problem, easy. My main concern is that some devs will—like me—be looking for why this wouldn’t work.

will be easy to implement it - will do it in next version!

Awesome 😁

[pkosiec]

I know it's been a while, but finally I started to work on this. Unfortunately I have to put this feature on hold, as it would change Mongo Seeding API - specifically, it would make readCollectionsFromPath function asynchronous.
It is because of dynamic import (import()), which needs to be used to import ES modules (.mjs files) with ES6 modules syntax.
I would like to keep API changes for 4.0, as I want to totally rewrite Mongo Seeding to have simpler an more convenient API.

As a workaround, one may use Babel to convert ES6 modules to CommonJS files, in order to import them with Mongo Seeding.

[danielbayerlein]

Any news to support ESM?

[pkosiec]

I'm sorry, but it won't land anytime soon. I had actually two attempts (this is the latest one: link) to do it but it became too complex to me. There are some caveats like experimental Jest ESM support, and also I would like to keep the backward compatibility - that is, support both ESM and CJS. This is tricky, especially that I'm out of the TS/JS community for quite a long time.

I'm open for contributions though!