Atmosphere packages exports and npm deps

[lorensr]

http://guide.meteor.com/writing-packages.html#exporting

export const myName = 'my-package';

What if you want your package to support apps < 1.3? Can you also api.export('myName') in package.js?

Is it best practice to use named exports, or should we explain defaults as well?

http://guide.meteor.com/writing-packages.html#npm-dependencies

Meteor packages can include npm packages to use JavaScript code from outside the Meteor package ecosystem, or to include JavaScript code with native dependencies.

If your package is using a dependency on the server then you can include npm packages in your Meteor package by using Npm.depends.

Does this mean only on the server? Can't use npm modules on the client inside a package?

Does Npm.depends always go on top level, or can you do eg

Package.onTest
  Npm.depends({
    sinon: '1.17.3'
  })
  ...

[tmeasday]

What if you want your package to support apps < 1.3? Can you also api.export('myName') in package.js?

If you want your package to support < 1.3 you need to use api.addFiles (rather than api.mainModule) and thus api.export also. You'd basically have to rewrite your files too as you can't use import / export.

Is it best practice to use named exports, or should we explain defaults as well?

I'm honestly not sure. It's not clear yet what the consensus is going to be in the wider JavaScript world as ES2015 support is pretty new everywhere.

We've gone with named exports as it's what you get by accident if you write the old api.export style (which happens to be what most of core Meteor does).

Does this mean only on the server? Can't use npm modules on the client inside a package?

It doesn't, you're right. We should change this.

Does Npm.depends always go on top level

Yes, although I can see how it would make sense to put it at a lower level (e.g. using it for peer deps in test mode).

[lorensr]

If you want your package to support < 1.3 you need to use api.addFiles (rather than api.mainModule) and thus api.export also. You'd basically have to rewrite your files too as you can't use import / export.

Thanks, worth noting in guide?

[tmeasday]

I guess, I'm not quite sure how--there's not any guide-style documentation anywhere about how to do this (it would be great to link to the 1.2 guide but it didn't have a writing packages section), and I wouldn't want to devote a lot of space to something I wouldn't really encourage people to do..

[stubailo]

Probably worth noting in the docs under package.js?

[lorensr]

api.mainModule is documented under modules:

http://docs.meteor.com/#/full/modules

Also, should it be explained there rather than here how to import using CommonJS, if you haven't switched your app to ecmascript? Similar to:

meteor/meteor#6636

[lorensr]

@tmeasday should we keep export default as the way to do React components? Relates to our discussion of how ListContainer gets it's name:

#397 (comment)

Should it instead be explicitly named as a named export?

[TimeBandit]

The issue I raised was more to do with how the documentation read.
Listcontainer is referenced a few lines down below the code snippet in the article but it is not clear as to where it it came from.

[tmeasday]

I think there's no reason not to name default exports as it makes it a lot clearer, even if it doesn't actually do anything (unless you access the export later down in the exporting file).

[tmeasday]

Also, should it be explained there rather than here how to import using CommonJS, if you haven't switched your app to ecmascript? Similar to:

We should possibly make some changes to the docs; let's hold off on this (just about to launch a new docs site).