UNPKG

5.69 kBJavaScriptView Raw
1// This file is the source for constructing a `package.json` file.
2// JSON is a wonderful interchange format, but due to the fact that the
3// [JSON Specification](http://json.org) does not allow for comments, I find
4// it horrid for self documenting examples.
5//
6// JavaScript allows for comments and inherently allows JSON. This file will
7// act as the source for building a `package.json` file that also manages this
8// package.
9//
10// It is the closest I can get to a self-documenting `package.json` file.
11
12
13//Before executing this file for the first time do:
14//npm install fs-extra
15//in the sites directory
16
17// The `package.json` file always consists of one top level object, which is
18// what we export here in a [Node.js](http://nodejs.org) friendly way that
19// will allow us to build our `package.json` file. A real `package.json` file
20// will not contain the `exports = ` definition, nor any of these comments.
21module.exports = {
22 // Many of the following `package.json` parameters are optional depending
23 // on whether or not this package will ever be published, and depending
24 // on how much management we want to delegate to npm. I did not mark
25 // optional vs. not-optional for the parameters, as a `package.json` file
26 // is by its nature always optional.
27
28 // Our npm package name needs to be unique only if we are going to publish
29 // our package into an npm registry. If we aren't going to publish the
30 // package the name can be anything we want.
31 //
32 // Leave off redundant affixes like `node-package` or `package-js`.
33 // We know it is JavaScript for Node.
34 "name": "projectname",
35 // A single line, or sometimes slightly longer, description of our package.
36 "description": "Scaffold for a website using bb-server and html-builder",
37 // [npm](http://npmjs.org) enforces the X.Y.Z semantic version
38 // scheme that is described at [http://semver.org/](http://semver.org/)
39 // and we should follow this versioning for our package.
40
41 //If this option is falsy, the version in the package.json is bumped
42 // "version": "0.1.0",
43 // URL to the homepage for this package.
44 "homepage": "https://github.com/michieljoris/projectname",
45
46 // Where is the source of truth for this code, and what type of repo is it?
47 "repository": {
48 "type": "git",
49 "url": "https://github.com/michieljoris/projectname.git"
50 },
51 // Every package should have at least one author. There are a couple of
52 // formats for the author. I prefer the explicit object format as follows:
53 "authors": [
54 "Michiel van Oosten <mail@axion5.net>"
55 ],
56 // What licenses govern this code, and where is the license associated
57 // with this code?
58 // The complex form, "licenses", is an array of objects.
59 // The simplest form is "license", and may point to just a string that
60 // represents the standard name of the license, like "MIT".
61
62 "license": "MIT",
63
64 // "moduleType": [
65 // "amd"
66 // ],
67
68 "ignore": [
69 "**/.*",
70 "node_modules",
71 "bower_components",
72 "test",
73 "tests"
74 ],
75 // If there is a file that should be loaded when require()ing this
76 // folder-as-a-package, declare this file here, relative to our package
77 // structure.
78 // "main": "lib/shift-calendar.js",
79
80 // What other modules/libraries do we require for our own module?
81 // The beauty of this dependencies block is that these modules will
82 // be downloaded magically when we run npm install from within our
83 // directory. npm itself will sort out any dependency conflicts within
84 // our own dependencies and we can be pretty much assured that the
85 // modules we need will be ready to run.
86 //
87 // **NOTE:** We don't have any dependencies for this module. See the
88 // `devDependencies` block for the way to include dependencies.
89 "dependencies": {
90 //node
91 "angular": "~1.2.14",
92 "angular-ui": "~0.4.0",
93 "modernizr": "~2.7.2",
94 //amd
95 "bootstrap": "~3.1.1",
96 "foundation": "~5.2.0",
97 "jquery-ui": "~1.10.4",
98 "normalize.css": "~3.0.0"
99
100 },
101 // What dependencies are useful only for developers?
102 // Installed when we `npm install` in our working directory, but not
103 // when people require our package in their own package.json. This is the
104 // usual and accepted place to put test frameworks and documentation
105 // tools.
106 //
107 // The packages we depend on for development:
108 // * **doccoh**: Documentation utility for this code.
109 "devDependencies": {
110 // "doccoh": "0.4.1"
111 },
112 // Should this package be prevented from accidental publishing by npm?
113 // The default is false (not hidden), but I include this here for doc
114 // purposes.
115 "private": false
116};
117
118
119// Small script used to write the package.json file out from the package.js
120// file.
121
122var fs = require("fs-extra");
123var bowerjs = require("./bower.js");
124var v = '0.0.0';
125
126if (!bowerjs.version) {
127 try {
128 v = require('./bower.json').version;
129 } catch(e) {
130 console.log('Created new bower.json. You\'re at version 0.0.0.');
131 }
132 var s = v.split('.');
133 v = [s[0],s[1],parseInt(s[2]) + 1].join('.');
134 bowerjs.version = v;
135}
136
137console.log("Writing the bower.json file out from bower.js...");
138fs.writeJSONFile("bower.json", bowerjs, function(err){
139 if (err) {
140 console.log("Error writing bower.json");
141 console.log(err);
142 console.log("");
143 }
144 else {
145 console.log(bowerjs);
146 console.log("\nbower.json written successfully.");
147 console.log("");
148 }
149});