0

e.g.

// lib.js
export function f1() {}
export function f2() {}
export * as default; // invalid syntax

And then in another file:

// app.js
import lib from './lib.js';
lib.f1();

Is there a way to do this without exporting each function explicitly? e.g.

export default {f1, f2}; // tedious

PS: I am aware that I can import * as lib from './lib.js'.

mpen
  • 272,448
  • 266
  • 850
  • 1,236

3 Answers3

2
import * as lib from './lib';
export default lib;

should be enough. So the module imports all of its own exports and then exports itself as its default export.

I'll second Bergi's answer though, this isn't great from an API design standpoint, and will probably be slower. If something is using your module and needs to import from it, it should know what it's importing, or ask for them all on its own, your module shouldn't do it for them.

loganfsmyth
  • 156,129
  • 30
  • 331
  • 251
  • You can import yourself?? How does that not create a recursion bomb? – mpen Apr 28 '16 at 22:30
  • 1
    It doesn't need to be a problem, you're essentially grabbing a reference to the module's exports, before the exports have been initialized, but after they've all been parsed. – loganfsmyth Apr 28 '16 at 22:57
1

I am aware that I can import * as lib from './lib.js'.

And you really should. Don't make your API more confusing than it needs to be.

If you still want to default-export your own module namespace object, you can also do

export * as default from "./lib.js"; // self-reference
Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • 1
    That syntax is proposal, and also doesn't currently allow `default`, though I did file an issue to see if that was intentional: https://github.com/leebyron/ecmascript-export-ns-from/issues/1 – loganfsmyth Apr 28 '16 at 22:55
  • @loganfsmyth: Ah, I knew I should've checked before posting this. [I really should have known](http://stackoverflow.com/a/34072770/1048572). – Bergi Apr 28 '16 at 23:18
  • How does this make my API more confusing? I'm not using `default` for anything else, it just saves you from writing `* as` every time you use the lib. 99% of the time you *want* the namespace, and if you don't for some reason, you still have that option. – mpen Apr 29 '16 at 01:25
  • "`* as`" is not that long, and makes clear what you are importing (to both the programmer and the engine which might have optimisations based on this). In contrast, having a namespace that contains itself is just… weird, in my eyes. – Bergi Apr 29 '16 at 13:33
  • Think of a library like lodash. What would you expect `import _ from 'lodash'` to do? I'd say that's pretty clear it's giving me the typical lodash object; there is no other default that makes sense here, really. Optimizations... do you have any sources to back that up? Would it become un-tree-shakable if we export the full object as default? – mpen Apr 30 '16 at 17:06
  • If I were using lodash in ES6, I'd do `import {map, pluck, …} from "lodash";` anyway. As for optimisations, it doesn't become impossible, but it's an edge case that might not be considered in tree-shaking. – Bergi Apr 30 '16 at 17:51
0

heres another option:

lib.js

export default {
   someFunctionOne: () =>  {

   },

   someFunctionTwo: () =>  {

   },


   someFunctionThree: () =>  {

   }
};

app.js

import lib from './lib';

lib.someFunctionOne();
glued
  • 2,579
  • 1
  • 25
  • 40