Add UMD

[OliverJAsh]

This module should work in CommonJS, AMD, and browser globals. Currently it only works for AMD.

Ideally this wrapping would be done as part of the build process.

Re. https://github.com/guardian/scribe/issues/77

[guybedford]

As a package author your priority is typically ensuring that it can be consumed as widely as possible. So having a flexible process for authoring to a wide number of formats / destinations is important.

A UMD pattern will always require manual config of third-party dependencies, but it will be useful to some users.

The only way to automate third-party dependencies is by using a registry system. npm kind of wins by ubiquity right now so you could compile to CommonJS and publish to npm. The dependency parameters are handled during the publish configuration process.

One can skip the middle steps and just author directly to npm, but it's the flexibility I'm trying to advocate.

[callum]

Might be worth exploring that npm route. I foresee the publish configuration being particularly tricky.

Thanks @guybedford.

[guybedford]

I believe self-executing bundles through jspm was also mentioned as a possible solution to this issue. Just to update that this feature is live in jspm 0.7 now - https://github.com/jspm/jspm-cli#4-creating-a-self-executing-bundle.

[theefer]

Lots of great thoughts in here, I'm hoping to get the time to pitch in soon as it'd be great to move towards an ES6 and UMD-compatible world!

[johannish]

@janfoeh Would you publish your umd build somewhere? I'm 3/4 of the way to having my own build, but getting stuck with the scribe-plugin-intelligent-unlink-command.js with Browserify's --standalone option.

My attempt attaches all the plugins to a Scribe.plugins global.

[janfoeh]

@raztus yes, I've had issues as well, although with the sanitizer plugin. Here is my intelligent unlink build. Three caveats, though: it's from September, I believe I haven't used it yet, and it exports to window.scribePluginIntelligentUnlinkCommand.

[pedrosanta]

+1 for more module formats or global somehow. Wiring up Angular and Require JS isn't the prettiest of things.

[jonsamwell]

Is there a way to use this without any fancy dependency management wrappers via just normal script tags. I also get a 'define is not defined' error when loading and I really don't want to have to include RequireJS to get this working.

[aeneasr]

+1 any news on this?

[WickyNilliams]

Would you accept a PR converting scribe to CommonJS, adding in browserify and outputting a UMD build?

[hmgibson23]

@WickyNilliams - we'd certainly look at it!

[lpil]

:+1:

[theefer]

UMD is on the way out, really. Would be more progressive to port Scribe to ES6 modules, and optionally build CJS/AMD targets.

[lpil]

Even better :)

[skeggse]

@theefer I've already ported Scribe to ES6 modules, and it works great internally - mind if I try pushing it upstream to this repo?

[danburzo]

I can confirm. We needed to have Scribe in ES6 modules format, and it has been relatively painless to rewrite the codebase itself. Would it be a good idea to have a separate Scribe branch that just has all its source code remapped to modules, even if tests, and build tools, and other parts that now depend on AMD need to be redone? I can see the value of just allowing the source of Scribe to be imported in a project, and let the project team decide how to bundle it and its dependencies.

[codeclown]

I have gone through everything I've been able to find on this subject, and still haven't really understood what the status is other than that apparently using Scribe via npm is not possible right now, unless you manually build the npm build as is done in the examples/cjs.html example.

Even a global binding as an option would be nicer. I'll much rather include a script-tag to the page than fiddle with some random build process for one dependency (or include require.js).

As others have suggested, it would be simple to port Scribe to use ES6 modules, and after that it would be just one browserify command in the build process to compile it to all module systems (CommonJS, AMD, global).

I'm willing to take part in the process of porting to ES6 modules (the repetitive work). I don't have extensive experience on publishing such a package via npm, but I'm sure someone would be able to help with that (@WickyNilliams for example proposed it already).

Question to maintainers: would this be a pull request you'd merge, assuming it would simply be a port of the current version in ES6 and with a build process outputting a fits-everything module?

Questions to others: anyone interested in helping with the PR, if maintainers confirm it'd be merged? As said, I can do the porting to ES6 modules, but would appreciate help ensuring the build process works great for npm and others.

[danburzo]

I can chip in with whatever needs to be done on this.

[xsbchen]

@danburzo why not?