Here is reproduction of the issue
User gets the object like { default: function, foo: function } so then to actually use the library it's necessary to use lib.default() to access main functionality. I understand why it works like this. However we have a use case that could actually benefit from exporting default function instead of a whole exports object.
See our UMD build here. We have a default export which is the main function. And this function gets also attached all other functions that are normally exported. By exporting this function, user would not lose any options, only gain in accessibility.
I am wondering if it could be configurable to have UMD bundle that points to default export?
See https://github.com/rollup/rollup/wiki/JavaScript-API#exports for an explanation of the exports option – by default, it will guess the mode based on what the entry module exports.
The only way you can avoid consumers having to do lib.default() is exports: 'default'. If you explicitly set that but also have named exports, it will throw, because that's logically incoherent – instead you would need to sacrifice the named exports and attach them to the default export as properties:
assign(stampit, allUtilities);
export default stampit;
If you want to create an ES module build (e.g. so that Rollup and Webpack 2 users have a more seamless way of importing, and can tree-shake etc) then you'd just need to have a separate entry point – e.g. you could have an index-umd.js entry point that looks like the previous code block, and an index-es.js that looks like this:
export default stampit;
export { methods, properties, ... };
Then, you'd create your main UMD bundle from index-umd.js, and your module/jsnext:main from index-es.js.
Ok I see. So generally you are against adding it as built in optional feature to use default export in UMD build instead of exports object? I guess your approach will probably work as well, it's just not that nice :)
Most helpful comment
See https://github.com/rollup/rollup/wiki/JavaScript-API#exports for an explanation of the
exportsoption – by default, it will guess the mode based on what the entry module exports.The only way you can avoid consumers having to do
lib.default()isexports: 'default'. If you explicitly set that but also have named exports, it will throw, because that's logically incoherent – instead you would need to sacrifice the named exports and attach them to the default export as properties:If you want to create an ES module build (e.g. so that Rollup and Webpack 2 users have a more seamless way of importing, and can tree-shake etc) then you'd just need to have a separate entry point – e.g. you could have an
index-umd.jsentry point that looks like the previous code block, and anindex-es.jsthat looks like this:Then, you'd create your
mainUMD bundle fromindex-umd.js, and yourmodule/jsnext:mainfromindex-es.js.