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

Encountered an issue with ionViewDidLoad: The property 'firstChild' cannot be read as it is null

Transitioning a GitHub repository to an organization: Handling NPM and Bower registry entries

Is the NPM package located in the /node_modules directory but still unable to be located?

Nextjs doesn't render the default JSX for a boolean state on the server side

The Angular service successfully provides a value, yet it fails to appear on the webpage

Passing a complex variable type in TypeScript to a function without the need to redefine the type

MQTT: The method net.createConnection does not exist

Tips for adding a mat-error to a mat-input-field on-the-fly

Screen remains blank as the React webpage fails to load

Is it necessary to generate a "custom.scss" file each time I start a fresh bootstrap project?

Utilize an enum to serve as a blueprint for generating a fresh object?

ngOnInit unable to properly listen to event stream

Compelling users to provide feedback on an App with the Ionic Framework

Display a dynamic array within an Angular2 view

Steps to resolve npm ERR! Unexpected end of JSON input error when parsing near '...m":"b569e8103ed5b2ad3'

Issue: I am unable to locate the module '../../package.json' when attempting to run npm on the command line. Even running 'npm -v' results in an error message

Issues with Laravel mix scripts not detecting any changes in the code

Encountering an issue with installing node modules on a Mac M1 device, resulting in errors

The count of bits is not producing the anticipated result

What is the process for instructing npm to install custom library dependencies found within a specific library on npm central?