NPM postinstall-only dependencies

user_2557145 0
Viewed 401

I am using git to distribute an internal TypeScript NPM package. As I don't want to have build files in my repository, I am using a postinstall action to build the package when it is installed:

"postinstall": "tsc -p tsconfig.json"

To build my package, some dependencies (e.g. TypeScript) are required. However, when I add them as dev dependencies, they are not available in the postinstall phase, so I have to add them as regular dependencies.

So my questions are:

  • Are there any drawbacks from having these build dependencies declared as regular dependencies in my package.json?
  • If so, what would be the preferred way to express build-only dependencies in NPM packages that are installed via git?
yarnpkg npm typescript
2 Answers

I have to strongly disagree with zamber's answer. There are pretty major drawbacks with declaring all your dependencies as prod dependencies. If you do this anyone who installs your package will also install all of your dev dependencies in their node_modules folder. This might not seem like much of an issue at this point but imagine if everyone did this. Also remember that it's not just people that install your project it's people who install any dependency that uses your project.

node_modules folders are already huge and npm install already takes a long time. If everyone added dev dependencies as prod the bandwidth, processing power and hard disk space requirements would go up very significantly.

In a lot of my projects there are really very few real dependencies but many, large dev dependencies: building dependencies (like typescript), testing dependencies like jest or jasmine, linting dependencies, even entire browsers for automtion tests. No one other than you needs these dependencies so should not have to pay in both time and hard drive space for them.

The way to publish TS libs is to build before you publish. That means that none of the dev dependencies are required.

user_1517700

Are there any drawbacks from having these build dependencies declared as regular dependencies in my package.json?

I don't think so. You either ways need them to build the package so there's no going around it unless you would commit built files.

Alternatively, you could provide only the source files and make building the responsibility of your users.

Another option is to branch it. Assuming master has your source files, create a dist branch and never merge it back to master, then on dist commit the built files and when you want to release a version merge master to dist, build, commit, push. This would give you more control over updates and make it easier for consumers.

Generally keeping artifacts in your repo is acceptable if you're authoring a library that will be used in other projects. Saves install time and hassle for users.

One possible drawback of this post-install build scheme is that your consumers may overload your build dependencies with package.json resolutions.

user_12257410
Related