Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FLUID-5799, FLUID-5967: Reducing Fragility #5

Merged
merged 23 commits into from Jan 24, 2017
Merged
Show file tree
Hide file tree
Changes from 18 commits
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
c863229
FLUID-5799: Check existence of remote repo
jobara Nov 27, 2015
d8bf7b2
FLUID-5799: Refactored to log all exec commands
jobara Nov 28, 2015
a64ac5f
FLUID-5799: Providing hints when errors occur.
jobara Aug 11, 2016
4a37de5
NOJIRA: Updated to ESLint and linted code
jobara Aug 11, 2016
2edf5c8
FLUID-5799: Version bump
jobara Aug 11, 2016
bf764ca
NOJIRA: Updated fluid-grunt-eslint to fix count of linted files
jobara Aug 24, 2016
140c2cd
FLUID-5799: Bumping node requirement to 4.0.0
jobara Aug 30, 2016
0a69275
NOJIRA: Updating Linting rules
jobara Aug 31, 2016
be30428
FLUID-5967: added an option to get the module's version
jobara Sep 22, 2016
49e5978
NOJIRA: Updating grunt dependency
jobara Sep 27, 2016
36feebf
NOJIRA: Updated to sharable eslint config
jobara Oct 3, 2016
cd241fc
FLUID-5799: Cleaning up README
jobara Oct 3, 2016
cb85d89
FLUID-5799: Command line options refactored
jobara Oct 3, 2016
099f773
FLUID-5799: Removed "\n" from log statement
jobara Dec 8, 2016
0e0d366
FLUID-5799: Fixed unit tests
jobara Dec 8, 2016
7a4f85a
FLUID-5799: Cleanup after updating version in dev builds
jobara Dec 8, 2016
74478a1
FLUID-5799: Refactoring getCLIOpts and updating related docs
jobara Dec 8, 2016
66d5a98
FLUID-5799: Fixing bug with tagging dev releases
jobara Dec 20, 2016
2775e6a
FLUID-5799: Updating hint descriptions
jobara Jan 12, 2017
3ed2231
FLUID-5799: Clarifying tag requirements for dev releases.
jobara Jan 12, 2017
e663e25
FLUID-5799: using publishDevHint for dev releases
jobara Jan 12, 2017
35a2d3c
FLUID-5799: Updated test comment
jobara Jan 12, 2017
f7da24a
FLUID-5799: More clarifications to the publishDevHint
jobara Jan 24, 2017
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
Empty file added .eslintignore
Empty file.
3 changes: 3 additions & 0 deletions .eslintrc.json
@@ -0,0 +1,3 @@
{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please could you update this to our new shared eslint repo - thanks!

"extends": "eslint-config-fluid"
}
1 change: 0 additions & 1 deletion .jshintignore

This file was deleted.

28 changes: 0 additions & 28 deletions .jshintrc

This file was deleted.

21 changes: 8 additions & 13 deletions Gruntfile.js
@@ -1,5 +1,5 @@
/*
Copyright 2015 OCAD University
Copyright 2015-2016 OCAD University

Licensed under the New BSD license. You may not use this file except in
compliance with this License.
Expand All @@ -8,34 +8,29 @@ You may obtain a copy of the License at
https://github.com/fluid-project/first-discovery-server/raw/master/LICENSE.txt
*/

// Declare dependencies
/* global module */
/* eslint-env node */
"use strict";

module.exports = function (grunt) {
"use strict";

// Project configuration.
grunt.initConfig({
// Project package file destination.
pkg: grunt.file.readJSON("package.json"),
jshint: {
all: ["**/*.js"],
buildScripts: ["Gruntfile.js"],
options: {
jshintrc: true
}
eslint: {
all: ["**/*.js"]
},
jsonlint: {
all: ["package.json", ".jshintrc"]
all: ["*.json", ".*.json", "tests/*.json"]
}
});

// Load the plugin(s):
grunt.loadNpmTasks("grunt-contrib-jshint");
grunt.loadNpmTasks("fluid-grunt-eslint");
grunt.loadNpmTasks("grunt-jsonlint");

// Custom tasks:

grunt.registerTask("default", ["lint"]);
grunt.registerTask("lint", "Apply jshint and jsonlint", ["jshint", "jsonlint"]);
grunt.registerTask("lint", "Apply eslint and jsonlint", ["eslint", "jsonlint"]);
};
160 changes: 125 additions & 35 deletions README.md
Expand Up @@ -15,7 +15,7 @@ npm install fluid-publish --save-dev

## Usage ##

### Command Line ###
### Command Line API ###

Run these commands from the root directory of the module to be published.

Expand All @@ -27,6 +27,20 @@ fluid-publish
./node_modules/.bin/fluid-publish
```

#### --version ####

__value__: true (Boolean)

Returns the current version of the Fluid-Publish module itself. No publishing
steps will occur when this flag is enabled.

```bash
# returns the version of fluid-publish
fluid-publish --version
# fluid-publish 2.0.0
```


#### --standard ####

__value__: true (Boolean)
Expand Down Expand Up @@ -54,25 +68,23 @@ fluid-publish
fluid-publish --standard
```

#### --options #####
#### options #####

__value__: {String} stringified JSON object
Optional key/value pairs, in the form `key=value`, to override the default configuration used across the publish script. The defaults can be found in publish.js's [package.json](package.json) file under the `defaultOptions` key.

A stringified JSON object containing overrides to the default options used across the publish script. The defaults can be found in publish.js's [package.json](package.json) file under the `defaultOptions` key.
<em><strong>NOTE</strong>: If only a <code>key</code> is provided, the value is assumed to be <code>true</code></em>

(See: [Options](#options))
(See: [Options](#options), [process.argv](https://nodejs.org/docs/latest/api/process.html#process_process_argv))

```bash
# publishes a dev build and applies the tag "nightly" to it
fluid-publish --options="{'devTag': 'nightly'}"
fluid-publish devTag="nightly"
```

### Node ###
### JavaScript API ###

##### parameters #####
fluid.publish can also be accessed through standard JavaScript function calls in a [node](https://nodejs.org) app.

* isTest {Boolean} - Indicates if this is a test run, if true a tarball will be generated instead of publishing to NPM.
* options {Object} - The defaults can be found in publish.js's [package.json](package.json) file under the `defaultOptions` key. (See: [Options](#options))

#### `dev` ####

Expand All @@ -83,10 +95,10 @@ var publish = require("fluid-publish");
publish.dev();
```

##### parameters #####
##### arguments #####

* isTest {Boolean} - Indicates if this is a test run, if true a tarball will be generated instead of publishing to NPM.
* options {Object} - The defaults can be found in publish.js's [package.json](package.json) file under the `defaultOptions` key. (See: [Options](#options))
1. isTest {Boolean} - Indicates if this is a test run, if true a tarball will be generated instead of publishing to NPM.
2. options {Object} - The defaults can be found in publish.js's [package.json](package.json) file under the `defaultOptions` key. (See: [Options](#options))

#### `standard` ####

Expand All @@ -97,6 +109,11 @@ var publish = require("fluid-publish");
publish.standard();
```

##### arguments #####

1. isTest {Boolean} - Indicates if this is a test run, if true a tarball will be generated instead of publishing to NPM.
2. options {Object} - The defaults can be found in publish.js's [package.json](package.json) file under the `defaultOptions` key. (See: [Options](#options))

## Options ##

<table>
Expand Down Expand Up @@ -125,6 +142,17 @@ publish.standard();
"git status -s -uno"
</td>
</tr>
<tr>
<td>
<code>checkRemoteCmd</code>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This material doesn't appear in this diff (yet) but this is the closest line:

i) There's a typo where "--standard" appears twice, presumably the first instance should be "--version"
ii) The heading named "Node" is pretty confusing and it's unclear what it refers to. There should be some text here to explain what is being documented
iii) There then seems to be some kind of missing heading since the docs then continue with "parameters" again which is a duplicate.
iv) The JSON-encoded form for accepting "options" will be pretty hard for users to use. We should instead accept standard UNIX-style key-value pairs which will be applied to the options individually - for example,

fluid-publish remoteName="origin" --standard

etc.

</td>
<td>
The CLI to execute which determines if the remote repository exists. This prevents trying to push a version control tag to a repo that doesn't exist.
</td>
<td>
"git ls-remote --exit-code ${remote}"
</td>
</tr>
<tr>
<td>
<code>rawTimestampCmd</code>
Expand Down Expand Up @@ -171,45 +199,30 @@ publish.standard();
</tr>
<tr>
<td>
<code>versionCmd</code>
<code>publishDevCmd</code>
</td>
<td>
The CLI to execute which sets the dev version to release under.
<ul>
<li>
<code>${version}</code> will be substituted with the generated dev build version.
</li>
</ul>
The CLI to execute which publishes a development release to NPM.
Uses the value specified by the `devTag` option.
</td>
<td>
"npm version --no-git-tag-version ${version}"
<br>
<br>
<p>
<em><strong>NOTE</strong>: This command will update the version in the package.json file, but will not commit the change.</em>
</p>
"npm publish --tag ${devTag}"
</td>
</tr>
<tr>
<td>
<code>distTagCmd</code>
<code>versionCmd</code>
</td>
<td>
The CLI to execute which tags an NPM release.
The CLI to execute which sets the dev version to release under.
<ul>
<li>
<code>${packageName}</code> will be substituted with executing module's name.
</li>
<li>
<code>${version}</code> will be substituted with the generated dev build version.
</li>
<li>
<code>${tag}</code>will be substituted with the value from the <code>devTag</code> option.
</li>
</ul>
</td>
<td>
"npm dist-tag add ${packageName}@${version} ${tag}"
"npm version --no-git-tag-version ${version}"
<br>
<br>
<p>
Expand Down Expand Up @@ -298,6 +311,83 @@ publish.standard();
"dev"
</td>
</tr>
<tr>
<td>
<code>remoteName</code>
</td>
<td>
The remote repository to push version control tag to.
</td>
<td>
"upstream"
</td>
</tr>
<tr>
<td>
<code>changesHint</code>
</td>
<td>
A hint for addressing uncommitted changes.
</td>
<td>
"Address uncommitted changes: Commit \"git commit -a\", Stash \"git stash\" or Clean \"git reset --hard\"\n"
</td>
</tr>
<tr>
<td>
<code>checkRemoteHint</code>
</td>
<td>
A hint for addressing an issue where the remote repository cannot be found.
</td>
<td>
"Run \"git remote -v\" for a list of available remote repositories.\n"
</td>
</tr>
<tr>
<td>
<code>publishHint</code>
</td>
<td>
A hint for addressing an issue where publishing to the registry fails.
</td>
<td>
"Ensure that you have access to publish to the registry and that the current version does not already exist.\n"
</td>
</tr>
<tr>
<td>
<code>publishDevHint</code>
</td>
<td>
A hint for addressing an issue where publishing to the registry fails.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Description should distinguish from publishHint

</td>
<td>
"Ensure that you have access to publish to the registry and that the current version does not already exist.\nIf the tag already exists use a new tag name or run \"npm dist-tag rm ${packageName} ${tag}\" to remove the existing one.\nAlso ensure that the tag name is valid (i.e. doesn't conform to a valid semver range like v1.4 or 1.4).\n"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last sentence is puzzlingly worded - is it the case that a tag name CANNOT correspond to a semver version, or is it the opposite?

</td>
</tr>
<tr>
<td>
<code>vcTagHint</code>
</td>
<td>
A hint for addressing an issue where applying a version control tag fails.
</td>
<td>
"If the tag already exists, run \"git tag -d v${version}\" to remove the existing tag.\n"
</td>
</tr>
<tr>
<td>
<code>pushVCTagHint</code>
</td>
<td>
A hint for addressing an issue where pushing a version control tag to a remote repository fails.
</td>
<td>
"If the tag already exists, run \"git push ${remote} :refs/tags/v${version} to remove the existing tag.\n"
</td>
</tr>
</tbody>
</table>

Expand Down
27 changes: 18 additions & 9 deletions package.json
@@ -1,10 +1,10 @@
{
"name": "fluid-publish",
"version": "1.1.0",
"version": "2.0.0",
"description": "A command line tool and node module that can be used to simplify the process of publishing a module to NPM. This is particularly useful for creating development releases, e.g. nightly or continuous integration releases.",
"main": "publish.js",
"engines": {
"node": ">=0.12.0"
"node": ">=4.0.0"
},
"scripts": {
"pub": "node publish.js",
Expand All @@ -30,27 +30,36 @@
"homepage": "http://fluidproject.org",
"dependencies": {
"es6-template-strings": "2.0.0",
"extend": "^3.0.0"
"extend": "3.0.0"
},
"devDependencies": {
"grunt": "^0.4.5",
"grunt-contrib-jshint": "~0.9.0",
"grunt": "1.0.1",
"eslint-config-fluid": "1.0.0",
"fluid-grunt-eslint": "18.1.2",
"grunt-jsonlint": "1.0.4",
"sinon": "^1.17.1"
"sinon": "1.17.1"
},
"defaultOptions": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note for the future - this strategy of packing configuration options into package.json is cute, but doesn't actually enable reuse of the functionality. In order to customise these strings, the user has to fork this module and change them! When we start work on the "mature multirepo fluid-publish" sketched out in #7, we should move this module over to being a standard Infusion component and have all these options as part of its defaults.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the default values aren't easily modifiable. In execution they are, but I agree that's not great for reuse and building upon.

"changesCmd": "git status -s -uno",
"checkRemoteCmd": "git ls-remote --exit-code ${remote}",
"rawTimestampCmd": "git show -s --format=%ct HEAD",
"revisionCmd": "git rev-parse --verify --short HEAD",
"packCmd": "npm pack",
"publishCmd": "npm publish",
"publishDevCmd": "npm publish --tag ${devTag}",
"versionCmd": "npm version --no-git-tag-version ${version}",
"distTagCmd": "npm dist-tag add ${packageName}@${version} ${tag}",
"cleanCmd": "git checkout -- package.json",
"vcTagCmd": "git tag -a v${version} -m 'Tagging the ${version} release'",
"pushVCTagCmd": "git push upstream v${version}",
"pushVCTagCmd": "git push ${remote} v${version}",
"devVersion": "${version}-${preRelease}.${timestamp}.${revision}",
"devTag": "dev",
"moduleRoot": ""
"remoteName": "upstream",
"moduleRoot": "",
"changesHint": "Address uncommitted changes: Commit \"git commit -a\", Stash \"git stash\" or Clean \"git reset --hard\"\n",
"checkRemoteHint": "Run \"git remote -v\" for a list of available remote repositories.\n",
"publishHint": "Ensure that you have access to publish to the registry and that the current version does not already exist.\n",
"publishDevHint": "Ensure that you have access to publish to the registry and that the current version does not already exist.\nIf the tag already exists use a new tag name or run \"npm dist-tag rm ${packageName} ${tag}\" to remove the existing one.\nAlso ensure that the tag name is valid (i.e. doesn't conform to a valid semver range like v1.4 or 1.4).\n",
"vcTagHint": "If the tag already exists, run \"git tag -d v${version}\" to remove the existing tag.\n",
"pushVCTagHint": "If the tag already exists, run \"git push ${remote} :refs/tags/v${version} to remove the existing tag.\n"
}
}