What is the correct way with NPM to package a BUILT version of a forked Git repository?

Viewed 405

I recently forked a GitHub repository to fix a problem, and created a pull request. While I wait for the pull request to be accepted, I have pointed my local package.json at my forked repo, like so:

devDependencies: {
    "karma-mocha": "maloric/karma-mocha"
}

However it turns out that karma-mocha requires a build step to be executed to generate lib/adapter.js - a vital part of the package. This file is listed in .gitignore, so does not exist in the repository. The build step is a grunt task that is normally executed when the package is published to npm, so adapter.js exists in the downloaded npm module.

My question is this: what is the correct way to package a forked, built version of the repository so that I can use it as a dependency? As far as I can tell, I have the following options:

  1. Build the repository locally, create a .tgz file with the built files, then host this somewhere and point my package.json to that file.
  2. Build the repository locally, alter .gitignore to allow adapter.js, then push to a branch on Github and use that branch as my dependency.

Either of these would work, but I feel like I am missing something. Does npm have a concept of forked packages? Not every git repository can be used as a dependency without some sort of build/dist step, so what is the accepted way to do this kind of thing?

1 Answers
Related