Examples are not working

[smnarnold]

All throw the same error
card-stack.js:4 Uncaught ReferenceError: gajus is not defined

[elmariachi111]

I analyzed the project's history a little bit. Note that the latest release 3.0.2 is quite outdated compared to the master. @gajus decided to migrate the build process to his own build helper pragmatist (which looks quite promising btw) but he broke the build / examples doing so.

I was able to create a working build by

• rolling back commit that exposed the gajus.* globals 1e852aa

• build on the command line:

  npm run pragmatist build --es5 (should create all source files, transpiled to es5 in dist)
  mkdir dist/browser
browserify dist/index.js > dist/browser/swing.js (bundles everything the way before)

now the examples work again on my machine.

see latest commit on https://github.com/elmariachi111/swing/tree/fix-build (this is not supposed to become a PR soon since I guess gajus has a pretty good reason for his changes ;) At least I don't want to mess around with gajus' changes in his build process and I hope he's going to finalize it soon)

[cryptic-mystic]

@elmariachi111 thanks a ton. I had gotten up to browserify but then saw Stack and Card weren't a part of the gajus object. UGH.

[gajus]

I am not actively maintaining this project. I will review PRs, etc., but I haven't got time to provide active support.

[elmariachi111]

@gajus yep, I thought so. When "fixing" up the pragmatist based build (it's actually not broken but users must use some kind of dependency management to require the dist files) I noticed that the "final step" (building some release file, compatible to e.g. the tons of jQuery applications out there) is missing. What is your suggestion: go on with pragmatist (are you're going to maintain that one?) or roll back to are more "commonly understood" standalon gulp file / webpack config and start adding features from there. Aka: is the current master from your point of view a dead end or definitely the way to go? Thanks for the code anyway, works amazingly well for me!

[gajus]

Aka: is the current master from your point of view a dead end or definitely the way to go? Thanks for the code anyway, works amazingly well for me!

Pragmatist is just a simple abstraction of gulp.

I am using pragmatist because it isolates implementation. In the specific case of Swing, user needs to only know npm run build, npm run test, npm run lint. However, few people bother doing as much as running npm run to learn available commands (or lack familiarity with CLI in the first place).

The project is no way dead. I left it at the stage where it works. It is being used in its current state in several projects (including The New Yorker, yay). There were no major feature requests and there are no bugs that I am aware of. (If I am wrong, please ping me.)

[elmariachi111]

Problem is: the master version isn't compiling the files as expected by the examples (they refer to ./../../dist/browser/swing.js) and their control file ("card-stack.js") expects gajus.Swing.Stack to exist on window (as many dependent projects may do that decided against using browserify e.a. or simply want to go the "plain" jQuery way ;) )

[cryptic-mystic]

However, few people bother doing as much as running npm run to learn available commands (or lack familiarity with CLI in the first place).

Agreed, however even running the npm tasks will not produce working examples (even though it may provide the proper build artifacts). Plus there's the extra step of running browserify to bundle into a single js file to get the examples to work. A little extra documentation can reduce friction of a dev getting started to extend this library (which I will happily volunteer to start).

Otherwise, this library is great! Easily readable / understandable code. I just spent the morning adding swipe up/down abilities which seem to be working well. Thanks for your work!

[cryptic-mystic]

@elmariachi111 so browserify works for initing the global gajus object for the examples. However swing.js is exporting the wrong JS objects... Any ideas? Looks like there's a webpack config in earlier revisions of the project but that tool is giving me problems as well.

[elmariachi111]

It's actually not exporting "wrong" objects, it's just not epxosing them on a global scope :) If you're using say browserify in your own project you can just require('swing') (which requires index.js by default) and get back Stack and Card objects. Would look like

var swing = require('swing');
var stack = new swing.Stack( ... );
stack.createCard( element );

[cryptic-mystic]

Ahhh I hear ya! I'm actually using this for a non-Node project, and we're relying on RequireJs for our front end modules. For things like swing that don't define AMD modules I've been configuring as shims. However when I do this define('myModule', ['swing'], function (swing) {}); the swing object returns the Hammer constructor... it's strange.

I'll keep playing around with it. For now I've added stuff back to the gajus globals, so thats kinda working. Thanks for your help! I'm a total noob when it comes to js modules.

[gajus]

Problem is: the master version isn't compiling the files as expected by the examples (they refer to ./../../dist/browser/swing.js) and their control file ("card-stack.js") expects gajus.Swing.Stack to exist on window (as many dependent projects may do that decided against using browserify e.a. or simply want to go the "plain" jQuery way ;) )

I didn't realise that. A simple fix would be to add webpack config and use it to create a bundle. Can someone raise a PR?

[cryptic-mystic]

I can play around with it over the weekend and see if I can get webpack working again :)

Translating the files to es5 seems sufficient for NPM projects, but others will require a single swing.js bundle right? So should dist/browser/swing.js be added to the repo once the build is fixed?

[gajus]

Translating the files to es5 seems sufficient for NPM projects, but others will require a single swing.js bundle right? So should dist/browser/swing.js be added to the repo once the build is fixed?

No, please don't. It would only encourage a malpractice of not using a module bundler.

[gajus]

Fixed. Follow instructions in https://github.com/gajus/swing/tree/910813e37018a548d37762f43d23c180c650f20b/examples