Hacker News Reader

Is there a reason for using non-standard language features for module imports?

> const m3o = require("m3o")(process.env.M3O_API_TOKEN);

Should be using ES modules, and then allowing the creation of the m3o object with the supplied API token. This future proofs the code, because ES modules are part of the language spec. CommonJS/RequireJS was only ever a hack.

> import { m3o } from 'm3o';

View on HN

I'm not sure why we did it that way. Will get one of the guys on the team to respond. I think it was about simplifying that initialisation but I sort of understand what you're saying. We still allow per API intialisation in the way you've mentioned.

> import { AddressService } from 'm3o/address'

At the time of writing the examples for the site we decided to use require as we had a lot of new Node.js developers and wanted to make sure they could just get going without having to know how to compile their code.

We will potentially move to import in the future, but people asked for require when the examples previously used imports.

With the package you can user import as an ES Module version is available:

> import M3O from 'm3o'; > const m3o = M3O(process.env.M3O_API_TOKEN);

Note: As long as the M3O_API_TOKEN environment variable is provided via a .env file then this is not required to be passed.

Reply on news.ycombinator.com