theoy / npm-git-publish Goto Github PK

If more than one publisher is trying to publish to the same Git remote, it's possible for some one else to win in between the clone and commit/push.

This makes the push no longer a fast-forward push, and some Git remotes may reject it.

Recovering and adjusting the parent commit is a more resilient way to react to this race condition.

Windows validation is important for private package / enterprise scenarios

Before finalising the commit/pushing, users may wish to transform the package in ways that are undesirable during prepublish.

For example:

• Autogenerating pre-release version numbers (e.g. based on commit hash of the source repo)
• Transforming file: dependencies to some other value that is more conducive to redistribution.

Both of the above transform examples are useful to do at publish time, but are not very useful to do at dev time (esp when a dev is just doing an npm install).

'nuff said 😄

If same tag exists and has same contents, it should be a graceful skip

If same tag exists and has different contents, it should be recognised as a conflict

As of npm 6.2.0, cleaning a specific package from the cache is no longer supported, so I get this error out:

{ Error: Command failed: npm cache clean mypackage@myversion
npm ERR! npm cache clear does not accept arguments

npm ERR! A complete log of this run can be found in:
npm ERR!     path\to\npm-cache\_logs\currentdatestamp-debug.log

    at ChildProcess.exithandler (child_process.js:275:12)
    at emitTwo (events.js:126:13)
    at ChildProcess.emit (events.js:214:7)
    at maybeClose (internal/child_process.js:925:16)
    at Socket.stream.socket.on (internal/child_process.js:346:11)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at Pipe._handle.close [as _onclose] (net.js:567:12)
  killed: false,
  code: 1,
  signal: null,
  cmd: 'npm cache clean mypackage@myversion' }

Getting the packfile name from the output of npm pack is actually troublesome because Package.json prepublish scripts also run, and can contribute to stdout - making it hard to parse.

Instead, understand the algorithm that npm uses to generate the final filename.

Everything but the package directory and git URL can be converted to optional parameters that hang off an options object.

Perhaps a user already has tarballs saved elsewhere. Might be convenient to share a module that handles the Git publishing part.

In hindsight, we don't need packageDirectory as a require parameter either.

Sometimes people use different git user IDs (e-mails) for different repositories.

Because this creates temporary repositories, if someone is invoking from within a repository with a custom ID, then that custom ID is not used in the new temporary repository. Instead, the default git user ID is used (global across the user's OS account).

This should default to process.cwd() if cwd is inside a repository, and provide the option to override with a custom context directory.

require('npm') instead of relying on $PATH

Man, I thought npm didn't have an API for some reason!

http://blog.izs.me/post/1675072029/10-cool-things-you-probably-didnt-realize-npm

Maybe a consumer wants to publish more than once at a given state.

This can definitely happen if they want to apply different prepublish transforms for each invocation.

We could save some work for repeat pushes of the same input.

Hash-based versioning is a transform, but it always need to be applied last - with a sentinel value (could be empty or 0) in all the locations that the hash will go, and then replaced at the very end.

To support this in a less error-prone way, ideally it would be special-cased as a transform.

Also, ideally it would be easy to opt in (since this is a good way to version your pre-releases).

Some might find an API too intimidating and prefer a CLI approach

Is there a way to push a different README.md file to the published repo?

Right now pushes always go to the remote's default branch. Provide an option to push to a different branch.

For users who want improved performance on our Git-based operations, support detecting if 'node-git' is installed and optionally use that instead of shelling out.