Publish to npm #100

jasonkarns · 2018-06-11T14:06:39Z

Updates to package.json for publishing to npm.

author/contributor details good?
compatibility with bpkg package.json format for scripts and binaries bpkg/bpkg#17
keywords?

The referenced issue from bpkg indicates that they intend to move off of package.json, or otherwise find a way to make bpkg's use compatible with npm. Per that issue, I don't know if that has happened or not. But as this PR stands at present, I believe it will break compatibility with bpkg due to the conflicting semantics of scripts.

For now, my intention is to first get the metadata correct (authorship info, keywords, etc) and publish the currently tagged versions to the npm registry. This can occur without having the package.json merged to master, so we don't necessarily have to resolve the bpkg compatibility issue immediately.

I have reviewed the Contributor Guidelines.
I have reviewed the Code of Conduct and agree to abide by it

jasonkarns · 2018-06-11T14:23:42Z

I should note a couple more things in the package:

files are included explicitly in the tarball via the files stanza. This way the published tarball only includes necessary files.
bins are specified via directories.bin (which is mutually exclusive with the bin stanza)
contributor metadata was taken from github profiles
the scripts I expect will eventually cover publishing to npm, docker, and version bumping. I would like to see these steps follow the https://github.com/github/scripts-to-rule-them-all pattern, but is immaterial to getting 1.0.0 and 1.0.1 published.

mbland · 2018-06-11T14:20:58Z

package.json

 {
  "name": "bats",
-  "version": "v1.0.1",
+  "version": "0.4.0",


Any reason why this is set back from v1.0.1?

I'm going to publish both 1.0.0 and 1.0.1 versions once the rest of the metadata is approved, so (for this PR which won't be merged) I'm keeping it at the old version. That way if I forget to bump it before attempting to publish, it'll error (existing version).

(FYI, I intend to publish from the commits actually tagged per version)

mbland · 2018-06-11T14:22:04Z

package.json

-  "repository": "github:bats-core/bats-core",
-  "bin": "./bin/bats"
+  "license": "MIT",
+  "author": "Sam Stephenson <[email protected]> (http://sstephenson.us/)",


Though Sam's the original author, of course, I wonder if it wouldn't be more accurate to list https://github.com/bats-core as the author and Sam as a contributor.

Eh, the definitions I typically adhere to:

Author: The person/s or organization that created the project
Owner: The person/s who has administrative ownership over the organization or repository
Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project.
Contributors: Everyone who has contributed something back to the project.

https://opensource.guide/how-to-contribute/#anatomy-of-an-open-source-project

Obviously, there are many (conflicting) definitions and there's nothing that states github's version as authoritative. However, by switching to AUTHORS file for contributors, that kinda muddies the distinction (which could be seen as a good thing?)

I'd prefer to keep Sam as author in package.json, and move contributors to AUTHORS file. google seems to distinguish AUTHORS file from CONTRIBUTORS file: https://opensource.google.com/docs/releasing/authors/

I wouldn't mind re-addressing this if/when bats-core gets the official nod as maintained successor to bats.

As far as an official nod goes, it'd be lovely if that would happen, and I'd welcome and celebrate it, as that's the order of things I'd prefer (short of being able to contribute to the original project, obviating the need for a fork)—but I've stopped holding my breath.

Same. But until that happens and/or we significantly change the code, I'd prefer to just maintain status quo with him as author?

It's arguable we have, but it's not a blocker, just something about which I was curious to hear others' thoughts.

mbland · 2018-06-11T14:24:09Z

package.json

+  ],
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/bats-core/bats-core.git"


Is this for bpkg compatibility? The github:bats-core/bats-core ID meets the current package.json format: https://docs.npmjs.com/files/package.json#repository

This is the format that was generated by npm init. I'm cool switching to the terse form. (I just confirmed that yarn supports the same short form, so 👍 )

mbland · 2018-06-11T14:25:06Z

package.json

-  "bin": "./bin/bats"
+  "license": "MIT",
+  "author": "Sam Stephenson <[email protected]> (http://sstephenson.us/)",
+  "contributors": [


Would an AUTHORS file be more desirable? Just got the idea from https://docs.npmjs.com/files/package.json#default-values.

Yeah, I'm cool with that. Generally I try to minimize files in repo root. But since AUTHORS would (presumably) support non-node/npm tools, I'm 👍

mbland · 2018-06-11T14:26:57Z

package.json

+    "bin", "libexec", "man"
+  ],
+  "directories": {
+    "bin": "bin",


So directories.bin obviates the need for the bin parameter? https://docs.npmjs.com/files/package.json#directories

mbland

Not sure what other tweaks may be necessary, but I'm OK with the changes as they are.

This will eliminate the need to bump the version in the readme itself.

jasonkarns · 2018-06-12T03:38:09Z

Throw me your npm registry usernames and I'll add you as maintainers.

mbland · 2018-06-12T13:48:22Z

@jasonkarns My npm username is @mbland as well.

jasonkarns · 2018-06-12T15:12:05Z

1.0.0 and 1.0.1 have been published to npm. Merging this for now so it's ready for future releases.

mbland · 2018-06-18T22:00:02Z

@jasonkarns Just pushed 1.0.2. Mind pushing it to npm, or giving me collaborator permission, whatever is easiest in the short term?

jasonkarns · 2018-06-19T12:56:30Z

@mbland you should already have maintainer access. (sent invite last week or so?). ping me if that's not the case.

related, I would like to see how interested people might be in using npm version (major|minor|patch) to do the version bumping? that way it can do the version bump, update all the necessary files automatically, tag/commit, git-push and publish. It would make node a requirement for us maintainers, but as long as we're all publishing to npm anyway... /shrug (or we could have it published by CI? though it's still nice to have all the version bumping automated)

mbland · 2018-06-19T13:54:00Z

Oh! That's weird. I didn't get an invite email, and I still only see your badge on https://www.npmjs.com/package/bats. But I could click through on https://www.npmjs.com/package/bats/access, see myself listed, and then npm publish v1.0.2.

I'm leaning against using npm version to do the bumping, as I don't see it as much work and don't mind doing it manually; but if you want to figure out how to get it all to work, feel free to try. One thing I like to do that I don't see in https://docs.npmjs.com/cli/version is to do annotated tags, where I've been posting the release notes as well.

On a related note, I'm wondering if it might be worth moving the "Version history" from the README into its own CHANGES document or some such.

jasonkarns · 2018-06-19T13:58:37Z

annotated tags

I believe it does annotated tags by default, but it just uses the version number by default. I'll play around and see if we can customize that.

"Version history" from the README into its own CHANGES document

Strong agree. For other things, I also use hub to publish release notes to each github Release. Would be nice to have all that connected. (Release including link to changelog, etc)

jasonkarns requested a review from a team as a code owner June 11, 2018 14:06

ghost assigned jasonkarns Jun 11, 2018

ghost added the review label Jun 11, 2018

Updates package.json for npm publishing

1985338

jasonkarns force-pushed the npm branch from bfbd374 to 1985338 Compare June 11, 2018 14:18

mbland reviewed Jun 11, 2018

View reviewed changes

mbland approved these changes Jun 11, 2018

View reviewed changes

jasonkarns and others added 5 commits June 11, 2018 22:22

Move contributors to AUTHORS file

c34d98e

Short-form urls

f567174

1.0.1

f25388a

Add npm badge to readme

ae5b3d0

Remove version from readme

d1a16d2

This will eliminate the need to bump the version in the readme itself.

jasonkarns merged commit c31dfde into master Jun 12, 2018

ghost removed the review label Jun 12, 2018

jasonkarns deleted the npm branch June 12, 2018 15:12

mizo7777 approved these changes Jul 7, 2024

View reviewed changes

Uh oh!

Publish to npm #100

Publish to npm #100

Uh oh!

Conversation

jasonkarns commented Jun 11, 2018

Uh oh!

jasonkarns commented Jun 11, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jasonkarns Jun 11, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mbland left a comment

Choose a reason for hiding this comment

Uh oh!

jasonkarns commented Jun 12, 2018

Uh oh!

mbland commented Jun 12, 2018

Uh oh!

jasonkarns commented Jun 12, 2018

Uh oh!

mbland commented Jun 18, 2018

Uh oh!

jasonkarns commented Jun 19, 2018

Uh oh!

mbland commented Jun 19, 2018

Uh oh!

jasonkarns commented Jun 19, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jasonkarns Jun 11, 2018 •

edited

Loading