2013-05-26 21:58:59 +00:00
|
|
|
{
|
|
|
|
|
"name": "piskel",
|
2017-01-29 13:25:44 +00:00
|
|
|
"version": "0.10.0",
|
2016-06-04 08:43:22 +00:00
|
|
|
"description": "Pixel art editor",
|
|
|
|
|
"author": "Julian Descottes <julian.descottes@gmail.com>",
|
|
|
|
|
"contributors": [
|
|
|
|
|
"Vincent Renaudin"
|
|
|
|
|
],
|
2013-05-26 21:58:59 +00:00
|
|
|
"homepage": "http://github.com/juliandescottes/piskel",
|
2016-06-04 08:43:22 +00:00
|
|
|
"license": "Apache-2.0",
|
2013-05-26 21:58:59 +00:00
|
|
|
"repository": {
|
|
|
|
|
"type": "git",
|
|
|
|
|
"url": "http://github.com/juliandescottes/piskel.git"
|
|
|
|
|
},
|
Prepare for npm publishing
Introduces some small package changes that simplify publishing Piskel to NPM as a ready-to-use application.
Since Piskel is not simply a JavaScript "module" (not something one would 'require' into another application) its role as a package on npm is somewhat unconventional - it contains the release build of Piskel, ready to serve as a static website, and a small `piskel-root` utility that will print the absolute path to that content (which will have been installed who-knows-where by npm).
Mostly this works by adding the "files" and "bin" entries to package.json, and by adding an .npmignore file (which simply prevents npm from using your .gitignore and ignoring the built files that we want to ship).
With these settings in place you could publish to npm anytime (as long as you have permission) but I've added `preversion` and `postversion` scripts to simplify and automate the process. Here's how you publish a release:
```
npm login # If not already logged in
npm version [major|minor|patch|<other>] # see `npm help version` for more options
```
By itself this will lint, run the full test suite, do a release build, make sure the working directory is clean, bump the version number in package.json, commit the version number change and add a git tag with the new version, push the new version to GitHub and publish the release build output to npm.
If you don't have an npm account, create one at npmjs.com. You'll need to do the initial release.
An npm user should then be able to download the latest Piskel release by running `npm install piskel`. They could then find the location of Piskel's index.html by running `` `npm bin`/piskel-root `` (perhaps more useful for automation purposes... our own build copies the built Piskel release from its npm-installed location to a directory where it gets served by Rails).
By itself this may not seem _that_ useful, but it's a step toward making Piskel easier to embed with other appilications. I've got a start on the next big improvement, where a parent application can `require('piskel')` to get an API object that facilitates communication with the editor running within an iframe. You can see an early version of that at https://github.com/code-dot-org/piskel/pull/7
2016-06-18 00:07:03 +00:00
|
|
|
"files": [
|
|
|
|
|
"dest/prod",
|
|
|
|
|
"misc/scripts/piskel-root"
|
|
|
|
|
],
|
|
|
|
|
"bin": {
|
|
|
|
|
"piskel-root": "./misc/scripts/piskel-root"
|
|
|
|
|
},
|
|
|
|
|
"main": "./dest/prod/index.html",
|
2013-05-26 21:58:59 +00:00
|
|
|
"scripts": {
|
2014-04-28 21:13:44 +00:00
|
|
|
"test": "grunt test",
|
Prepare for npm publishing
Introduces some small package changes that simplify publishing Piskel to NPM as a ready-to-use application.
Since Piskel is not simply a JavaScript "module" (not something one would 'require' into another application) its role as a package on npm is somewhat unconventional - it contains the release build of Piskel, ready to serve as a static website, and a small `piskel-root` utility that will print the absolute path to that content (which will have been installed who-knows-where by npm).
Mostly this works by adding the "files" and "bin" entries to package.json, and by adding an .npmignore file (which simply prevents npm from using your .gitignore and ignoring the built files that we want to ship).
With these settings in place you could publish to npm anytime (as long as you have permission) but I've added `preversion` and `postversion` scripts to simplify and automate the process. Here's how you publish a release:
```
npm login # If not already logged in
npm version [major|minor|patch|<other>] # see `npm help version` for more options
```
By itself this will lint, run the full test suite, do a release build, make sure the working directory is clean, bump the version number in package.json, commit the version number change and add a git tag with the new version, push the new version to GitHub and publish the release build output to npm.
If you don't have an npm account, create one at npmjs.com. You'll need to do the initial release.
An npm user should then be able to download the latest Piskel release by running `npm install piskel`. They could then find the location of Piskel's index.html by running `` `npm bin`/piskel-root `` (perhaps more useful for automation purposes... our own build copies the built Piskel release from its npm-installed location to a directory where it gets served by Rails).
By itself this may not seem _that_ useful, but it's a step toward making Piskel easier to embed with other appilications. I've got a start on the next big improvement, where a parent application can `require('piskel')` to get an API object that facilitates communication with the editor running within an iframe. You can see an early version of that at https://github.com/code-dot-org/piskel/pull/7
2016-06-18 00:07:03 +00:00
|
|
|
"start": "nodewebkit",
|
2016-08-31 22:47:33 +00:00
|
|
|
"preversion": "grunt test build",
|
Prepare for npm publishing
Introduces some small package changes that simplify publishing Piskel to NPM as a ready-to-use application.
Since Piskel is not simply a JavaScript "module" (not something one would 'require' into another application) its role as a package on npm is somewhat unconventional - it contains the release build of Piskel, ready to serve as a static website, and a small `piskel-root` utility that will print the absolute path to that content (which will have been installed who-knows-where by npm).
Mostly this works by adding the "files" and "bin" entries to package.json, and by adding an .npmignore file (which simply prevents npm from using your .gitignore and ignoring the built files that we want to ship).
With these settings in place you could publish to npm anytime (as long as you have permission) but I've added `preversion` and `postversion` scripts to simplify and automate the process. Here's how you publish a release:
```
npm login # If not already logged in
npm version [major|minor|patch|<other>] # see `npm help version` for more options
```
By itself this will lint, run the full test suite, do a release build, make sure the working directory is clean, bump the version number in package.json, commit the version number change and add a git tag with the new version, push the new version to GitHub and publish the release build output to npm.
If you don't have an npm account, create one at npmjs.com. You'll need to do the initial release.
An npm user should then be able to download the latest Piskel release by running `npm install piskel`. They could then find the location of Piskel's index.html by running `` `npm bin`/piskel-root `` (perhaps more useful for automation purposes... our own build copies the built Piskel release from its npm-installed location to a directory where it gets served by Rails).
By itself this may not seem _that_ useful, but it's a step toward making Piskel easier to embed with other appilications. I've got a start on the next big improvement, where a parent application can `require('piskel')` to get an API object that facilitates communication with the editor running within an iframe. You can see an early version of that at https://github.com/code-dot-org/piskel/pull/7
2016-06-18 00:07:03 +00:00
|
|
|
"postversion": "git push && git push --tags && npm publish"
|
2013-05-26 21:58:59 +00:00
|
|
|
},
|
|
|
|
|
"devDependencies": {
|
2016-11-27 11:08:51 +00:00
|
|
|
"dateformat": "2.0.0",
|
2017-05-06 14:43:20 +00:00
|
|
|
"fs-extra": "3.0.1",
|
|
|
|
|
"grunt": "^1.0.1",
|
2016-08-31 12:11:29 +00:00
|
|
|
"grunt-casperjs": "^2.2.1",
|
2017-05-06 14:43:20 +00:00
|
|
|
"grunt-contrib-clean": "1.1.0",
|
2016-04-21 20:37:53 +00:00
|
|
|
"grunt-contrib-concat": "1.0.1",
|
2016-05-07 13:18:12 +00:00
|
|
|
"grunt-contrib-connect": "1.0.2",
|
2016-03-05 11:55:08 +00:00
|
|
|
"grunt-contrib-copy": "1.0.0",
|
2016-11-27 11:08:18 +00:00
|
|
|
"grunt-contrib-jshint": "1.1.0",
|
2017-05-06 14:43:20 +00:00
|
|
|
"grunt-contrib-uglify": "2.3.0",
|
2016-03-12 22:20:38 +00:00
|
|
|
"grunt-contrib-watch": "1.0.0",
|
2017-05-06 14:43:20 +00:00
|
|
|
"grunt-include-replace": "5.0.0",
|
|
|
|
|
"grunt-jscs": "3.0.1",
|
|
|
|
|
"grunt-karma": "2.0.0",
|
2015-12-09 21:38:58 +00:00
|
|
|
"grunt-leading-indent": "0.2.0",
|
2016-11-27 10:57:13 +00:00
|
|
|
"grunt-nw-builder": "3.1.0",
|
2014-07-23 17:42:08 +00:00
|
|
|
"grunt-open": "0.2.3",
|
2016-04-21 20:37:53 +00:00
|
|
|
"grunt-replace": "1.0.1",
|
2017-05-06 14:43:20 +00:00
|
|
|
"grunt-spritesmith": "6.4.0",
|
|
|
|
|
"jasmine-core": "2.6.1",
|
|
|
|
|
"karma": "1.7.0",
|
|
|
|
|
"karma-chrome-launcher": "2.1.1",
|
|
|
|
|
"karma-jasmine": "1.1.0",
|
|
|
|
|
"karma-phantomjs-launcher": "1.0.4",
|
|
|
|
|
"load-grunt-tasks": "3.5.2",
|
2016-08-31 15:25:20 +00:00
|
|
|
"phantomjs": "2.1.7",
|
2016-12-18 10:36:11 +00:00
|
|
|
"phantomjs-polyfill-object-assign": "0.0.2",
|
2017-01-15 13:07:04 +00:00
|
|
|
"promise-polyfill": "6.0.2",
|
|
|
|
|
"rmdir": "1.2.0"
|
2014-04-28 21:13:44 +00:00
|
|
|
},
|
|
|
|
|
"window": {
|
2014-06-21 20:39:37 +00:00
|
|
|
"title": "Piskel",
|
2016-08-06 02:06:49 +00:00
|
|
|
"icon": "dest/prod/logo.png",
|
2014-06-21 20:39:37 +00:00
|
|
|
"toolbar": false,
|
|
|
|
|
"width": 1000,
|
|
|
|
|
"height": 500
|
2013-05-26 21:58:59 +00:00
|
|
|
}
|
2013-05-27 21:42:16 +00:00
|
|
|
}
|