Extend usage

[Szayet]

@anseki Would it be possible to update the npm package version to support
Babel or Require.JS options? (Like how jQuery do it).

I'm developing a Meteor application which heavily rely on these option as it segments namespaces for all source files. Awesome package otherwise.

Currently if I try to:
const PlainOverlay = require('plain-overlay');
or
import PlainOverlay from 'plain-overlay'
I got an empy object as a result.

[anseki]

Hi @Szayet, thank you for the comment.

PlainOverlay was built by Webpack with Babel.
Therefore, of course you can import it to your project easily if you use Webpack to bundle it.
See https://github.com/anseki/plain-overlay/blob/master/webpack.config.js to build it.

[Szayet]

Hello @anseki, thank you for your fast reply. I'll look into it, however as a feature request I'm still asking for a pre-boundled / out of the box solution in npm as it would make sense imho. Ease of use, and the possibility to update the package thru npm would be a very nice get-go feature. :)

[anseki]

Of course PlainOverlay is being published on NPM, and you can install and update this package via NPM.
https://www.npmjs.com/package/plain-overlay
Sorry, my English is poor, and I might have misunderstood your words.

[Szayet]

@anseki And that is exactly why im suggesting an upgrade. According to my research if u set libraryTarget to umd and add umdNamedDefine: true as the next line, the builded library could be imported and required via es6 / commonjs.

[anseki]

Since this library is used for only client side, the UMD should not be specified. Also, that has side effects. And that is not needed to import it because any bundler is required for the client environment such as this library itself.

[Szayet]

I do not dispute the usefullness of the current setup, however on platforms builded upon node.js where npm package integrations is supported, and global/window namespaces are not (even for client codes) <script src=""></script> loading simply won't work as the library cannot be accessed from the boundled client codes.

However creating an es6 / commonj compatible package version of PlainOverlay (just like jQuery did with their npm package) it would solve our problem by enabeling the import PlainOverlay from 'plain-overlay' or const PlainOverlay = require('plain-overlay') route which is as I said the only viable options in some cases.

If the package got an umd wrap around it it could be still used by

    <script src="plain-overlay.min.js"></script>
    <script>var PlainOverlay = PlainOverlay.default;</script>

Until webpack2 corrects the ability to create a correct factory to dismiss the need of the .deault, which is already high in the feature request list.

And also would enable the npm package installers to write a meteor client code like f.e.:

meteor npm install PlainOverlay --save

then write something like this:

imports\ui\client\display.js

import PlainOverlay from 'plain-overlay';
var overlay = new PlainOverlay(document.getElementById(...)); 

P.S: If the .default is a grave problem, then having two minified version could easily solve it. The current version could be downloaded as is, whereas the npm package could come with the es6 / commonjs / babel compatible umd wrap approach.

[anseki]

Thank you for your suggestion.
I will consider that in future version, and that should not be merged for now.
As I said, the UMD should not be specified. And it's not required.
Also, you should not import the bundled version in JavaScript module system.
Remember why you use modules. The module system allow sharing codes, updating each part, etc.
Usually, the source code is used for the module system (i.e. import, require) in front-end, and PlainOverlay also has export default to allow import.
That is loaded via jsnext:main in package.json.

[Szayet]

Maybe then the npm package.json entry point could point to ./src/plain-overlay.js which would result in the same features as all the modifications I recommended so far. Thank you very much for your patience, as you can see I would realy love to use your awesome package inside my meteor application. 😃

[anseki]

Yes, you can import it to your project easily. Using source code makes your project more better than using UMD.
Thank you for praising, and your politely PR. 😄