Spine goes NPM
September 1st, 2021
Good news, everyone! After our work on the massive Spine 4.0 release, we freed up time to tie up some loose ends. Today, we're happy to report that we've finished modularzing our spine-ts runtimes!
NPM registry
Historically, spine-ts was published as in form of .js/js.map/d.ts files as emitted by the TypeScript compiler. While the simple inclusion of, for example, spine-player.js via a script tag made starting out with spine-ts easy, it wasn't super nice to use with more complex build pipelines. Anyone using NPM or Yarn for dependency management had to use various workarounds to include our simple .js files.
No more! Starting today, spine-ts and all its backends for Canvas, WebGL, Three.js, and the Spine Web Player are now fully modularized and published to the NPM registry. If you are using NPM or Yarn for dependency management in your project, you're a simple install away from using one of the backends:
npm install @esotericsoftware/spine-webgl
npm install @esotericsoftware/spine-canvas
npm install @esotericsoftware/spine-threejs
ECMAScript modules
We've made all components of spine-ts ECMAScript modules. These are understood by all the bundlers commonly in use, like webpack, Babel, Parcel, and esbuild. Once you've installed the spine-ts module you want to use via NPM or Yarn, you can access the exported constants, functions, and classes using the ECMAScript modules import syntax in your .js or .ts source files:
new spine.SpinePlayer("player", {
skelUrl: "assets/spineboy-pro.skel",
atlasUrl: "assets/spineboy-pma.atlas",
animation: "run",
premultipliedAlpha: true,
backgroundColor: "#cccccc",
viewport: {
debugRender: true,
},
showControls: true,
});
Your bundler of choice will then find the dependency in your node_modules folder and bundle it together with the rest of your application code.
You can find all our published modules on the npm registry with the @esotericsoftware scope. The packages not only contain the module code, but also source maps and typings, which will be used automatically by your bundler and IDE of choice.
Vanilla JavaScript
What does this mean for users of the old vanilla JavaScript/script tag approach? Well, we have good news there too! We are keeping that in tact, with only one very minor breaking change (sorry, it couldn't be avoided).
The constants, functions, and classes of the spine-canvas, spine-webgl, and spine-threejs backends have up until now lived in the global spine.canvas, spine.webgl, and spine.threejs objects. Due to our new build pipeline, that is no longer the case. All exported constants, functions, and classes are now on the global spine object, together with the classes from spine-core. All you need to do is find references to spine.canvas, spine.webgl, and spine.threejs in your code, and change them to spine. That's it!
CDN hosting
We'll keep publishing the .js/js.map files. However, their location has now changed. Instead of hosting them on our own server, you can get them from a proper CDN called UNPKG. They put all packages on the NPM registry on Cloudflare and add some magic to resolve versions.
So if you've previously included say spine-player.js from our server at: http://esotericsoftware.com/files/spine-player/4.0/spine-player.js
Then you should now use the equivalent UNPKG URL which would be: https://unpkg.com/@esotericsoftware/spine-player@4.0.4/dist/iife/spine-player.js
UNPKG also hosts source maps, as well as a minified version of each module, for example: https://unpkg.com/@esotericsoftware/spine-player@4.0.4/dist/iife/spine-player.min.js
Development setup
We've also improved the development setup for working on spine-ts itself quite a bit. If you are working off of a fork of spine-ts, this might also benefit you! Find out more in the spine-ts README.md.