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

Question

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?

Answer 1

That seems similar to karma-runner/karma-jasmine issue 38, not exactly the same library, but the same idea, and issue with adapter.js:

As you correctly pointed out, adapter.js generated by grunt build.
adpater.js is placed only in npm repository when we run grunt release.

If you want use your version of karma-jasmine then you can remove lib/adapter.js from .gitignore.

So option 2.