3 ms·
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 mod
by lloydatkinson 5y ago
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';
- asim 5y agoI'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'
- martinm3o 5y agoAt 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.