bespokejs / bespoke

DIY Presentation Micro-Framework
http://markdalgleish.com/projects/bespoke.js/
MIT License
4.68k stars 443 forks source link

Export bespoke when required as CJS module #34

Closed medikoo closed 10 years ago

medikoo commented 10 years ago

In current shape bespoke.js doesn't work well as CJS module, and it's quite surpring as it's hosted on npm.

Natural way of working with CJS (Node.js style) is to do:

var bespoke = require('bespoke');
var deck = bespoke.from('article', {
  // ...
});

This won't work as require('bespoke') doesn't export bespoke, it actually exports nothing which doesn't make much sense. We have to refer to global scope, which is quite dirty and may require additional lint configuration if we guard global leaks with lint tool

Currently we have to:

// Dirty, no CJS way:
require('bespoke');
var deck = bespoke.from('article', { // bespoke is global
  // ...
});

This change fixes that, without breaking global behavior

markdalgleish commented 10 years ago

Thanks for the pull request!

This is something I'm definitely interested in and I've spent quite a bit of time thinking about it, but I have a few concerns that have kept me from moving forward in the past.

First, I want to keep any module definition code out of the source file and only add it as part of the build process, generating a separate file for each supported format. I don't want to tie bespoke.js too closely to any module format just yet, especially with ES6 modules just around the corner.

If bespoke core used a CJS format, I'd like to make the entire plugin API also work well with it, for example:

var bespoke = require('bespoke');
var deck = bespoke.from('#presentation', [
  require('keys')(),
  require('touch')(),
  require('bullets')('li, .bullet')
]);

I see you've written some plugins, so you'll understand that the current plugin style won't support this. All existing plugins would need to be upgraded to support this.

What do you think?

medikoo commented 10 years ago

I personally use CJS all the way, and plan to switch to ES6 modules as soon as first stable versions of some engines (preferably Node.js) will support it out of a box.

It is closest to what we'll have in ES6 (future migration could be easily automatized) and code is executable everywhere without syntax transformation. You surely need to bundle it for browser, but your module is included in 1:1 form, with no transformations.

Additionally CJS easily compiles to any other, AMD or old school (globals) format as Bespoke now uses.

So CJS is great idea, and as you saw in my plugins for Bespoke, repository codebase ends up much lighter, and no generators, pre-compilations tasks setc. are really needed. :)

markdalgleish commented 10 years ago

I've been thinking about this further, and it's quite possible that proper CommonJS support will become a first-class citizen in the API in the future. Its implementation would be similar to my earlier comment, so I'm going to close this issue for now. At some point, I might open up the discussion elsewhere.

Thanks again for the pull request, I really appreciate it.