Dependencies exclusively for NPM post-installUnique Rewrite: "N

Question

Dependencies exclusively for NPM post-installUnique Rewrite: "N

I have been using git to distribute an internal TypeScript NPM package. To avoid cluttering my repository with build files, I have implemented a postinstall action to build the package upon installation:

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

In order to successfully build the package, certain dependencies (such as TypeScript) are necessary. However, including them as dev dependencies means they are not accessible during the postinstall phase, forcing me to declare them as regular dependencies.

My queries regarding this setup are:

Are there any disadvantages to specifying these build dependencies as regular dependencies in my package.json file?
If so, what is the recommended method for designating build-only dependencies in NPM packages installed via git?

typescript npm yarnpkg

Answer 1

Answer №1

I must express my strong opposition to zamber's viewpoint. There are significant drawbacks to defining all dependencies as production dependencies. By doing so, every person who installs your package will also be installing all of your development dependencies in their node_modules directory. While this may not seem problematic now, just think about the implications if everyone took this approach. Let's not forget that it's not just individuals installing your project; it's also those installing any dependency that utilizes your project.

The node_modules directories are already quite large, and npm install already consumes a considerable amount of time. If everyone were to include development dependencies as production dependencies, the demands on bandwidth, processing power, and hard disk space would skyrocket.

In many of my projects, there are only a few essential dependencies but numerous large development dependencies: tools for building (e.g., TypeScript), testing frameworks like Jest or Jasmine, code linting tools, and even entire web browsers for automation tests. These dependencies are strictly for internal use and should not impose time and storage burdens on others.

The recommended practice for publishing TypeScript libraries is to build before publishing. This ensures that none of the development dependencies are necessary.

Answer 2

I must express my strong opposition to zamber's viewpoint. There are significant drawbacks to defining all dependencies as production dependencies. By doing so, every person who installs your package will also be installing all of your development dependencies in their node_modules directory. While this may not seem problematic now, just think about the implications if everyone took this approach. Let's not forget that it's not just individuals installing your project; it's also those installing any dependency that utilizes your project.

The node_modules directories are already quite large, and npm install already consumes a considerable amount of time. If everyone were to include development dependencies as production dependencies, the demands on bandwidth, processing power, and hard disk space would skyrocket.

In many of my projects, there are only a few essential dependencies but numerous large development dependencies: tools for building (e.g., TypeScript), testing frameworks like Jest or Jasmine, code linting tools, and even entire web browsers for automation tests. These dependencies are strictly for internal use and should not impose time and storage burdens on others.

The recommended practice for publishing TypeScript libraries is to build before publishing. This ensures that none of the development dependencies are necessary.

Answer 3

Answer №2

Is it a potential issue to list these build dependencies as regular dependencies in my package.json file?

I believe not. These dependencies are necessary for building the package, so there's no way around including them unless you want to commit pre-built files.

Alternatively, you could choose to only provide the source files and leave the building process to your users.

Another approach is to create a separate branch for built files. Keep your source files on the main branch (like master) and have a branch for distribution (like dist). Whenever ready to release, merge master into dist, build, commit, and push. This method gives you more control over updates and simplifies things for users.

It's generally acceptable to store artifacts in your repository if you're developing a library intended for use in other projects. It saves time and effort for those consuming your library.

One drawback of this approach is that users might end up overriding your build dependencies using selective version resolutions in their own package.json files.

Answer 4

Is it a potential issue to list these build dependencies as regular dependencies in my package.json file?

I believe not. These dependencies are necessary for building the package, so there's no way around including them unless you want to commit pre-built files.

Alternatively, you could choose to only provide the source files and leave the building process to your users.

Another approach is to create a separate branch for built files. Keep your source files on the main branch (like master) and have a branch for distribution (like dist). Whenever ready to release, merge master into dist, build, commit, and push. This method gives you more control over updates and simplifies things for users.

It's generally acceptable to store artifacts in your repository if you're developing a library intended for use in other projects. It saves time and effort for those consuming your library.

One drawback of this approach is that users might end up overriding your build dependencies using selective version resolutions in their own package.json files.

Dependencies exclusively for NPM post-installUnique Rewrite: "N

Answer №1

Answer №2

Similar questions

What is the best choice for a package.json file in an ASP.NET MVC project: devDependencies or dependencies?

Learn how to manually trigger the opening of ngx-popover in Angular 2

Versions of Angular that are compatible with Ionic 2 (do not have an exported member)

The FormControl is currently presenting ",required(control)" within its value field

"Exploring the world of Typescript with the Drawflow library

"Attempting to verify a JSON Web Token using a promise that returns an object not compatible with the specified

The database is failing to reflect any changes even after using the db.insert function

Is there a way to transfer the opts/flags used in the npm install command to the postinstall scripts?

Tips for reverting from Angular 7 to Angular 6

Should private members be kept confidential during program execution?

The installation of Angular CLI through npm has unfortunately encountered an error

Steps for running a TypeScript project as a child process within a JavaScript project

Creating a customized environment variable for the global scope using Webpack build

Utilizing jspm for installing npm packages along with their dependencies

An issue occurred during the installation of the generator-mean-seed

Executing the jslint command on all files within a directory in cmd (specifically in the context of npm)

Error in Syntax for Raspberry Pi and Node-RED using npm

Validation errors in the realm of Zod

React-table fails to show newly updated data

Difficulty with setting up Typescript in Visual Studio Code on MacOS Catalina