I think your best bet is going to be using a module loader like RequireJS to pull both Snap.js and Snap.svg into you application in a controlled way, it looks like both support AMD module loaders.
Unfortunately this will mean you won't be able to rely on the snap-content
directive from Angular Snap anymore. You'll need to create a new Snap.js snapper instance yourself and make use of snapRemote#register
.
Here's some pseudo code:
require(['jakiestfu/Snap.js/snap'], function(SnapJS) {
snapRemote.register(new SnapJS(snapOptions));
});
require(['adobe-webplatform/Snap.svg/snap.svg'], function(SnapSVG) {
// Do stuff with SnapSVG...
});
Also, you'll want to assign a "snap-content"
class name to the element you initialize your snapper with (this is also usually handled by the snap-content
directive).
Edit:
I'm not recommending this approach but it should work as well if you don't mind some hacks:
In your head:
<script src="//cdn.jsdelivr.net/snap.svg/0.2.0/snap.svg.js" type="text/javascript"</script>
<script>
// Save Snap.svg before it gets clobbered!
window.SnapSVG = Snap;
</script>
<script src="snap.js" type="text/javascript" charset="utf-8"></script>
After that you could go on using the svg Snap as SnapSVG or whatever you want to call it. The module loader approach is arguably better in almost any way you want to look at it... unless you need to ship tomorrow :).
Edit 2:
I just released v1.5.0 of Angular Snap which makes the Snap.js constructor an injected dependency rather than something we just look for on the window. You could now provide your own constructor, maybe saving it before it gets clobbered:
myApp.config(function(SnapConstructorProvider) {
SnapConstructorProvider.use(window.Snap);
});
Using this you'll still be able to take advantage of the snap-content
directive even if you pull in the Snap.js script with a module loader.