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?
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.