Giter Club home page Giter Club logo

np's Introduction

np XO code style

A better npm publish

Why

  • Interactive UI
  • Ensures you are publishing from your release branch (main and master by default)
  • Ensures the working directory is clean and that there are no unpulled changes
  • Reinstalls dependencies to ensure your project works with the latest dependency tree
  • Ensures your Node.js and npm versions are supported by the project and its dependencies
  • Runs the tests
  • Bumps the version in package.json and npm-shrinkwrap.json (if present) and creates a git tag
  • Prevents accidental publishing of pre-release versions under the latest dist-tag
  • Publishes the new version to npm, optionally under a dist-tag
  • Rolls back the project to its previous state in case publishing fails
  • Pushes commits and tags (newly & previously created) to GitHub/GitLab
  • Supports two-factor authentication
  • Enables two-factor authentication on new repositories
    (does not apply to external registries)
  • Opens a prefilled GitHub Releases draft after publish
  • Warns about the possibility of extraneous files being published
  • See exactly what will be executed with preview mode, without pushing or publishing anything remotely
  • Supports GitHub Packages
  • Supports npm 9+, Yarn (Classic and Berry), and pnpm 8+

Why not

Prerequisite

  • Node.js 18 or later
  • npm 9 or later
  • Git 2.11 or later

Install

npm install --global np

Usage

$ np --help

  Usage
    $ np <version>

    Version can be:
      patch | minor | major | prepatch | preminor | premajor | prerelease | 1.2.3

  Options
    --any-branch            Allow publishing from any branch
    --branch                Name of the release branch (default: main | master)
    --no-cleanup            Skips cleanup of node_modules
    --no-tests              Skips tests
    --yolo                  Skips cleanup and testing
    --no-publish            Skips publishing
    --preview               Show tasks without actually executing them
    --tag                   Publish under a given dist-tag
    --contents              Subdirectory to publish
    --no-release-draft      Skips opening a GitHub release draft
    --release-draft-only    Only opens a GitHub release draft for the latest published version
    --test-script           Name of npm run script to run tests before publishing (default: test)
    --no-2fa                Don't enable 2FA on new packages (not recommended)
    --message               Version bump commit message, '%s' will be replaced with version (default: '%s' with npm and 'v%s' with yarn)
    --package-manager       Use a specific package manager (default: 'packageManager' field in package.json)

  Examples
    $ np
    $ np patch
    $ np 1.0.2
    $ np 1.0.2-beta.3 --tag=beta
    $ np 1.0.2-beta.3 --tag=beta --contents=dist

Interactive UI

Run np without arguments to launch the interactive UI that guides you through publishing a new version.

Config

np can be configured both globally and locally. When using the global np binary, you can configure any of the CLI flags in either a .np-config.js (as CJS), .np-config.cjs, .np-config.mjs, or .np-config.json file in the home directory. When using the local np binary, for example, in a npm run script, you can configure np by setting the flags in either a top-level np field in package.json or in one of the aforementioned file types in the project directory. If it exists, the local installation will always take precedence. This ensures any local config matches the version of np it was designed for.

Currently, these are the flags you can configure:

  • anyBranch - Allow publishing from any branch (false by default).
  • branch - Name of the release branch (main or master by default).
  • cleanup - Cleanup node_modules (true by default).
  • tests - Run npm test (true by default).
  • yolo - Skip cleanup and testing (false by default).
  • publish - Publish (true by default).
  • preview - Show tasks without actually executing them (false by default).
  • tag - Publish under a given dist-tag (latest by default).
  • contents - Subdirectory to publish (. by default).
  • releaseDraft - Open a GitHub release draft after releasing (true by default).
  • testScript - Name of npm run script to run tests before publishing (test by default).
  • 2fa - Enable 2FA on new packages (true by default) (setting this to false is not recommended).
  • message - The commit message used for the version bump. Any %s in the string will be replaced with the new version. By default, npm uses %s and Yarn uses v%s.
  • packageManager - Set the package manager to be used. Defaults to the packageManager field in package.json, so only use if you can't update package.json for some reason.

For example, this configures np to use unit-test as a test script, and to use dist as the subdirectory to publish:

package.json

{
	"name": "superb-package",
	"np": {
		"testScript": "unit-test",
		"contents": "dist"
	}
}

.np-config.json

{
	"testScript": "unit-test",
	"contents": "dist"
}

.np-config.js or .np-config.cjs

module.exports = {
	testScript: 'unit-test',
	contents: 'dist'
};

.np-config.mjs

export default {
	testScript: 'unit-test',
	contents: 'dist'
};

Note: The global config only applies when using the global np binary, and is never inherited when using a local binary.

Tips

npm hooks

You can use any of the test/version/publish related npm lifecycle hooks in your package.json to add extra behavior.

For example, here we build the documentation before tagging the release:

{
	"name": "my-awesome-package",
	"scripts": {
		"version": "./build-docs && git add docs"
	}
}

Release script

You can also add np to a custom script in package.json. This can be useful if you want all maintainers of a package to release the same way (Not forgetting to push Git tags, for example). However, you can't use publish as name of your script because it's an npm defined lifecycle hook.

{
	"name": "my-awesome-package",
	"scripts": {
		"release": "np"
	},
	"devDependencies": {
		"np": "*"
	}
}

User-defined tests

If you want to run a user-defined test script before publishing instead of the normal npm test or yarn test, you can use --test-script flag or the testScript config. This can be useful when your normal test script is running with a --watch flag or in case you want to run some specific tests (maybe on the packaged files) before publishing.

For example, np --test-script=publish-test would run the publish-test script instead of the default test.

{
	"name": "my-awesome-package",
	"scripts": {
		"test": "ava --watch",
		"publish-test": "ava"
	},
	"devDependencies": {
		"np": "*"
	}
}

Signed Git tag

Set the sign-git-tag npm config to have the Git tag signed:

$ npm config set sign-git-tag true

Or set the version-sign-git-tag Yarn config:

$ yarn config set version-sign-git-tag true

Private packages

You can use np for packages that aren't publicly published to npm (perhaps installed from a private git repo).

Set "private": true in your package.json and the publishing step will be skipped. All other steps including versioning and pushing tags will still be completed.

Public scoped packages

To publish scoped packages to the public registry, you need to set the access level to public. You can do that by adding the following to your package.json:

"publishConfig": {
	"access": "public"
}

If publishing a scoped package for the first time, np will prompt you to ask if you want to publish it publicly.

Note: When publishing a scoped package, the first ever version you publish has to be done interactively using np. If not, you cannot use np to publish future versions of the package.

Private Org-scoped packages

To publish a private Org-scoped package, you need to set the access level to restricted. You can do that by adding the following to your package.json:

"publishConfig": {
	"access": "restricted"
}

Publish to a custom registry

Set the registry option in package.json to the URL of your registry:

"publishConfig": {
	"registry": "https://my-internal-registry.local"
}

Package managers

If a package manager is not set in package.json, via configuration (packageManager), or via the CLI (--package-manager), np will attempt to infer the best package manager to use by looking for lockfiles. But it's recommended to set the packageManager field in your package.json to be consistent with other tools. See also the corepack docs.

Publish with a CI

If you use a Continuous Integration server to publish your tagged commits, use the --no-publish flag to skip the publishing step of np.

Publish to gh-pages

To publish to gh-pages (or any other branch that serves your static assets), install branchsite, an np-like CLI tool aimed to complement np, and create an npm "post" hook that runs after np.

npm install --save-dev branchsite
"scripts": {
	"deploy": "np",
	"postdeploy": "bs"
}

Initial version

For new packages, start the version field in package.json at 0.0.0 and let np bump it to 1.0.0 or 0.1.0 when publishing.

Release an update to an old major version

To release a minor/patch version for an old major version, create a branch from the major version's git tag and run np:

$ git checkout -b fix-old-bug v1.0.0 # Where 1.0.0 is the previous major version
# Create some commits…
$ git push --set-upstream origin HEAD
$ np patch --any-branch --tag=v1

The prerequisite step runs forever on macOS

If you're using macOS Sierra 10.12.2 or later, your SSH key passphrase is no longer stored into the keychain by default. This may cause the prerequisite step to run forever because it prompts for your passphrase in the background. To fix this, add the following lines to your ~/.ssh/config and run a simple Git command like git fetch.

Host *
 AddKeysToAgent yes
 UseKeychain yes

If you're running into other issues when using SSH, please consult GitHub's support article.

Ignore strategy

The ignore strategy, either maintained in the files-property in package.json or in .npmignore, is meant to help reduce the package size. To avoid broken packages caused by essential files being accidentally ignored, np prints out all the new and unpublished files added to Git. Test files and other common files that are never published are not considered. np assumes either a standard directory layout or a customized layout represented in the directories property in package.json.

FAQ

I get an error when publishing my package through Yarn

If you get an error like this…

❯ Prerequisite check
✔ Ping npm registry
✔ Check npm version
✔ Check yarn version
✖ Verify user is authenticated

npm ERR! code E403
npm ERR! 403 Forbidden - GET https://registry.yarnpkg.com/-/package/my-awesome-package/collaborators?format=cli - Forbidden

…please check whether the command npm access list collaborators my-awesome-package succeeds. If it doesn't, Yarn has overwritten your registry URL. To fix this, add the correct registry URL to package.json:

"publishConfig": {
	"registry": "https://registry.npmjs.org"
}

Maintainers

np's People

Contributors

bunysae avatar chinesedfan avatar dertimonius avatar dopecodez avatar drarig29 avatar erisds avatar fregante avatar g-rath avatar hypercubed avatar itaisteinherz avatar jamestalmage avatar jesstelford avatar jsaguilar avatar mifi avatar mmkal avatar natecavanaugh avatar nnmrts avatar ntwcklng avatar oligot avatar samverschueren avatar shazron avatar sholladay avatar sindresorhus avatar sonicdoe avatar tiagodanin avatar tommy-mitchell avatar unkillbob avatar voxpelli avatar yaodingyd avatar zikaari avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

np's Issues

version bump in manifest.json if present

I am writing a chrome extension and i want to update version in manifest.json too with package.json. Maybe an option to pass the path to manifest.json and get it updated will be great.

Install fails

$ npm install np --save
npm WARN package.json [email protected] No description
npm WARN package.json [email protected] No repository field.
npm WARN engine [email protected]: wanted: {"node":">=4"} (current: {"node":"0.10.37","npm":"1.4.28"})
npm ERR! 404 Not Found
npm ERR! 404 
npm ERR! 404 'sindresorhus/df' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it
npm ERR! 404 It was specified as a dependency of 'mount-point'
npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, or http url, or git url.

npm ERR! System Darwin 15.0.0
npm ERR! command "node" "/usr/local/bin/npm" "install" "np" "--save"
npm ERR! cwd /npm ERR! node -v v0.10.37
npm ERR! npm -v 1.4.28
npm ERR! code E404
npm ERR! not ok code 0

Tell user to fix problem instead of rebasing

Really cool module! I would love to start using this since I always forget to run npm publish. The only thing that got me a bit scared was the git pull --rebase.

I guessed that you are using this to make sure that the working tree is clean (git pull errors out otherwise; i think?) and that changes are synced with upstream (in this case I guess; that all remote changes are present locally).

Maybe it would be better to check for the cases specifically and warn the user?

@if test 0 -ne `git status --porcelain | wc -l` ; then \
  echo "Unclean working tree. Commit or stash changes first." >&2 ; \
  exit 128 ; \
  fi

@if test 0 -ne `git fetch ; git status | grep '^# Your branch' | wc -l` ; then \
  echo "Local/Remote history differs. Please push/pull changes." >&2 ; \
  exit 128 ; \
  fi

I found the code in rlidwka/url-unshort, Makefile

Validate arguments

Running np --help currently runs thru all the steps, but running npm version --help, found this one out the hard way 😆

I think it would be a great idea to start by validating that $1 is a valid bump specification.

Warn of (and cleanup?) tags that are ahead of package.json version

If package.json is at say v1.2.3 but a tag exists for v1.2.4, this is probably a mistake. Could np detect when tags have got ahead of package.json and offer an interactive dialog inviting the user to either remove the tag before publishing or to publish at the next available tag semver?

"Failed to execute process" on OS X

Full install & attempted run log:

$ npm install -g np                                                                                                                                                                     
/usr/local/bin/np -> /usr/local/lib/node_modules/np/np.sh
npm WARN unmet dependency /usr/local/lib/node_modules/jscs/node_modules/to-double-quotes/node_modules/meow/node_modules/indent-string requires get-stdin@'^4.0.1' but will load
npm WARN unmet dependency /usr/local/lib/node_modules/jscs/node_modules/to-double-quotes/node_modules/get-stdin,
npm WARN unmet dependency which is version 3.0.2
npm WARN unmet dependency /usr/local/lib/node_modules/jscs/node_modules/to-single-quotes/node_modules/meow/node_modules/indent-string requires get-stdin@'^4.0.1' but will load
npm WARN unmet dependency /usr/local/lib/node_modules/jscs/node_modules/to-single-quotes/node_modules/get-stdin,
npm WARN unmet dependency which is version 3.0.2
npm WARN unmet dependency /usr/local/lib/node_modules/livedown/node_modules/socket.io/node_modules/engine.io requires debug@'1.0.3' but will load
npm WARN unmet dependency /usr/local/lib/node_modules/livedown/node_modules/socket.io/node_modules/debug,
npm WARN unmet dependency which is version 2.1.0
npm WARN unmet dependency /usr/local/lib/node_modules/livedown/node_modules/socket.io/node_modules/socket.io-parser requires debug@'0.7.4' but will load
npm WARN unmet dependency /usr/local/lib/node_modules/livedown/node_modules/socket.io/node_modules/debug,
npm WARN unmet dependency which is version 2.1.0
npm WARN unmet dependency /usr/local/lib/node_modules/livedown/node_modules/socket.io/node_modules/socket.io-client requires debug@'0.7.4' but will load
npm WARN unmet dependency /usr/local/lib/node_modules/livedown/node_modules/socket.io/node_modules/debug,
npm WARN unmet dependency which is version 2.1.0
npm WARN unmet dependency /usr/local/lib/node_modules/livedown/node_modules/socket.io/node_modules/socket.io-adapter requires debug@'1.0.2' but will load
npm WARN unmet dependency /usr/local/lib/node_modules/livedown/node_modules/socket.io/node_modules/debug,
npm WARN unmet dependency which is version 2.1.0
[email protected] /usr/local/lib/node_modules/np
└── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected])
$ np                                                                                                                                                                              
Failed to execute process '/usr/local/bin/np'. Reason:
exec: Exec format error
The file '/usr/local/bin/np' is marked as an executable but could not be run by the operating system.

Ensure CI has passed

If .travis.yml exists, use the Travis API to verify the build for the latest commit has passed (this should come after ensuring the latest commit has been pulled down).

Same thing if appveyor.yml exits, use the AppVeyor API.

Both API's provide the commit sha, so it should be fairly easy.

If the CI build is pending, it would be really cool if we just awaited the build result (instead of failing). That way you could merge a commit into master and execute np immediately, knowing it will wait for CI to finish before actually publishing.

says i'm on a different version of npm than i'm actually using

Cannot use np. When I try to publish I get the following errors:

↳ np patch
 ✖ Prerequisite check
   Git
   Cleanup
   Installing dependencies
   Running tests
   Bumping version
   Publishing package
   Pushing tags

[email protected] has known issues publishing when running Node.js 6. Please upgrade npm or downgrade Node and publish again. https://github.com/npm/npm/issues/5082

However:

↳ npm --version
3.10.5
↳ which npm
/Users/todd/src/nvm/versions/node/v6.3.0/bin/npm
↳ npm ls -g npm
/Users/todd/src/nvm/versions/node/v6.3.0/lib
└── [email protected]
↳ nvm ls
->       v6.3.0
         system
↳ grep \"version\"  ~/src/nvm/versions/node/v6.3.0/lib/node_modules/npm/package.json
  "version": "3.10.5"

Exit when using node 6

Because of the npm publish bug, I guess it would be nice to check if the node version is >=6 and if that's the case, fail and suggest to downgrade.

optional CHANGELOG generation with conventional-changelog-angular format

Problem Statement

I've become a convert to using a conventional commit format when squashing commits on my various OSS projects:

  • with nyc and yargs I was finding it valuable to (and people requested that I) maintain a CHANGELOG:
    • it's useful for forensic analysis when bugs are released.
    • it helps communicate outwards to the community about the work you're doing.
  • unfortunately, I found that CHANGELOG maintenance was a nuisance -- it would add several minutes (at best) to the release cycle while I groomed the file, and collected information for it.

I wanted a CHANGELOG, but I didn't want to put work into maintaining it!

The Solution

  • I don't require that contributors to the project use a special commit format.
  • I take advantage of GitHub's squash button, and craft a formatted message while I land pull requests (this adds almost no cycles to my workflow).
  • I currently use the standard-version tool to cut a release from the git history that has been landed.

Here's what you end up with:

https://github.com/yargs/yargs/blob/master/CHANGELOG.md

Proposal

  • it would be great if we could add CHANGELOG support to np.
  • rather than requiring this functionality (I understand not everyone will want to craft commit messages) we could add a new option flag --changelog?

Why?

Various folks in the conventional-changelog org have expressed an interest in working together more closely with you (CC: @nexdrew, @Tapppi).

Personally, I'd like to find ways to continue standardizing on commit message format/release management. I'm excited by projects like @boennemann's semantic-release, I've also been talking to the folks at coveralls.io about the idea of creating activity feeds for your coverage history based on parsing this format (CC: @nickmerwin, @anjin).

tldr; there's lots of cool stuff happening around CI/CD right now, and we should try to work together as much as possible.

The command fails if the node_modules directory does not exist

This can occur if the previous np call was aborted.

trash node_modules
np
Error: Command failed: /Users/JM/.nvm/versions/node/v5.3.0/lib/node_modules/np/node_modules/trash/lib/osx-trash
Specify one or more paths

    at ChildProcess.exithandler (child_process.js:213:12)
    at emitTwo (events.js:87:13)
    at ChildProcess.emit (events.js:172:7)
    at maybeClose (internal/child_process.js:818:16)
    at Socket.<anonymous> (internal/child_process.js:319:11)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at Pipe._onclose (net.js:469:12)

prepublish hook?

I just found this repo through "node weekly" and love the idea. Your README mentions npm lifecycle hooks but seems to describe only a command-line interface? I would like to keep using the command npm publish but add "prepublish" and "postpublish" hooks corresponding to the steps that np performs before and after the actual publishing. Can I use np in those hooks to script only the specific steps? If that's possible, can you provide examples in your documentation? If not, is it on the roadmap?

Support --tag (dist-tag)?

Hiya - any interesting in adding an option to publish under a given dist-tag? Akin to npm publish --tag beta, etc.

Report on activity

It'd be great if np could report on what it's doing. With larger packages, it can hang for quite a while on several of the steps, and checking running processes isn't the best UX. I'd be happy to create a PR.

Is there a preferred reporter module? I.e., something that wraps console.log with timestamping, colors, whatever? I checked awesome-nodejs but couldn't find anything exactly for this purpose.

It's probably best if we make index.js export an EventEmitter and make cli.js do the actual reporting.

Support commit signing

I suspect that np hangs when trying to commit the version bump because I have signing required. It does not prompt for my passphrase and just hangs.

Does this differ from the gist?

Heya, I've been using the gist version of this for a while. Has anything changed from the gist, or is it just the same script in a repo?

`np` attempts to publish version twice

When I use np, I always get the following message (v1.0.2 --> v1.1.0 here)

v1.1.0
npm ERR! publish Failed PUT 403
npm ERR! Linux 4.2.0-35-generic
npm ERR! argv "/home/jeroen/.nvm/versions/node/v5.9.0/bin/node" "/home/jeroen/.nvm/versions/node/v5.9.0/bin/npm" "publish"
npm ERR! node v5.9.0
npm ERR! npm  v3.7.3
npm ERR! code E403

npm ERR! "You cannot publish over the previously published version 1.1.0." : lib-upgrader
npm ERR! 
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /home/jeroen/dev/lib-upgrader/npm-debug.log

The previous version did not exist, and it gets published all right, but somehow it attempts to publish the version twice (then crashes and does not push to the remote).

Skip the `npm publish` step

I know that this will mess-up the whole idea of:

A better npm publish

but it will be awesome if the npm publish step can be disabled, so it can be used also for local modules/projects. For example by checking the private field of package.json.

Check current git branch

So you make some cool changes and you are excited to release, with np at your side to scratch your trigger finger. Everything goes fine until you realize that you weren't on master at the time. You go to merge in your branch, but there are conflicts or you find out that some things that were supposed to be in the release didn't make it in. Hopefully the test suite has integration tests and the release isn't actually broken. But at the very least, you have to publish again. Hopefully the second release can simply be a patch (master didn't contain any new features or breaking changes), otherwise your dependents are more likely to get something weird.

To protect against this, I propose that np checks whether you are on master before proceeding. That may not be everyone's workflow, so it could be opt-out, but I think it's how the vast majority of np users release.

Happy to do a PR for this if there is interest.

Write this tool in Node.js

I was just wondering, why wasn't it written with node instead? Probably because it started out small. But I was looking into the issues and I think that switching to node would make things easier to implement. Just wanted your opinion, close if you think it doesn't makes sense :).

Tips for maintaining a changelog?

I've been starting to maintain a changelog in some of my projects, and I would have liked to have one single commit for both the changelog update and the release bump (while still using np obviously, it's pretty neat).

Currently, I don't think this is possible with np, except if I missed something.

Don't have patch as default

Surely it's quite dangerous - could lead to a breaking change being released as a patch by mistake. Wouldn't it be better to exit with a message on what the acceptable values are?

./node_modules/.bin/trash not working?

Firstly, thank you for this module, it's a great time saver : )

I've noticed that this line that trashes the node_modules directory doesn't seem to do anything. Though, no error is raised I believe because of the stdout redirection to /dev/null.

I've been able to verify this by modifying the global np.sh script by removing the npm install command, the rest of the script still works (the node_modules directory was never trashed).

❯ node -v
v5.1.1

❯ npm -v
3.5.1

Perhaps this broke with the npm@3 release?


Edit: I've tried to work on a patch, too, but seem to have run out of luck getting it to work.


Edit 2: I was able to get it working changing the call to /usr/local/lib/node_modules/np/node_modules/.bin/trash but that feels kinda hacky.

Fatal error when pushing to GitHub

Issue

While executing np major, a git-related error occurs while trying to push to GitHub.

$ np major
[ ... ]
fatal: You didn't specify any refspecs to push, and push.default is "nothing".
 ✖ Exitted with status 128.

Cause

This line does not specify the remote nor the branch, which is mandatory when having this in ~/.gitconfig:

[push]
  default = nothing

Reproduce bug

$ git config --global push.default nothing
$ np major

Possible fix

Make sure the remote and the branch are both specified:

exec('git', ['push', 'origin', 'master', '--follow-tags']);

`--skip-reinstall` flag

Not sure about the name, but a flag to skip reinstalling dependencies. Sometimes I'm on a really slow network and just need to get out a release fast and willing to YOLO.

Hide git subtasks

Can all the git tasks be executed concurrently? Since [email protected] we can now set the concurrent option to true. Same goes for the prerequisite tasks which should be extracted into a sublist in order to implement #70.

Add more tests

Issuehunt badges

I want to write more tests but testing this library is a little bit tricky. I see two options here.

  1. Mock the execa calls
  2. Checkout sindre-playground and run np

The first one doesn't really feel quite ok. Option number 2 looks much better but will create a lot of releases and noise.

Any other suggestions for adding more tests?


IssueHunt Summary

tommy-mitchell tommy-mitchell has been rewarded.

Backers (Total: $80.00)

Submitted pull Requests


Tips

cli repeating log

np_bug
While doing publishing or some cli based task the following bug happens.
My versions are:

$ npm -v
2.15.5
$ node -v
v4.4.6

Detect missing dependencies

Meaning, dependencies required/imported in the module, but not defined in dependencies. To ensure I don't publish a release that has the dependency incorrectly in the devDependencies field. Like in the sindresorhus/grunt-concurrent#85 case. Could maybe be a ESLint rule.

Skip dirty check on npm version step?

Running into a tricky situation with our modules that are published to private git repos:

  1. Starting with a clean master, run np patch
  2. np does dirty checking and everything is legit, moves on
  3. As a prerequisite to running the tests we do a build of the module which changes some of the dist files
  4. When np gets to the npm version step this step fails because the tree is now dirty

This is an unfortunate side effect of a) having dist files that we only want to update as part of a publish and b) having to commit those dist files to git because we npm install out of git.

I think what we need is to be able to npm version --force which as per the docs will skip the dirty check.

I'm hesitant to set force: true in npmrc or the package.json because:

  1. we'd have to do that on every repo we want to publish
  2. force applies to more than just the version command

Any thoughts on how we could support this? I'm trying to think how we can avoid adding another flag to np but am struggling to find a better idea. I'm quite happy to contribute the solution, just wanted to gather some input on what that solution should be first 👍

Flag to disable "node_modules" deletion.

My devDependencies take forever to download (Lots of Babel and ESLint packages).

node_modules are ignored by npm internally, and it's very common to .gitignore them too. So this isn't really beneficial in my eyes... It's basically just deleting and then downloading what I already had, and then not publishing them anyways.

It'd be nice if there were a flag to disable it so I didn't have to wait a long while for it to redownload my deps, such as --keep.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.