Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The peer deps of typescript causes it installed in production mode #622

Closed
OpportunityLiu opened this issue May 19, 2023 · 8 comments
Closed

Comments

@OpportunityLiu
Copy link

ref: #598 #606

With a package.json like:

{
  "devDependencies": {
    "typescript": "^5.0.4"
  },
  "dependencies": {
    "dep": "^1.0.0" // has a dependency of "type-fest"
  }
}

typescript will be installed even if in production mode (npm install --omit=dev, pnpm install --prod, or yarn install --prod).

How can I omit the typescript package in production mode?

@sindresorhus
Copy link
Owner

// @charpeni

@OpportunityLiu
Copy link
Author

https://nodejs.org/en/blog/npm/peer-dependencies

UPDATE: npm versions 1, 2, and 7 will automatically install peerDependencies if they are not explicitly depended upon higher in the dependency tree. For npm versions 3 through 6, you will receive a warning that the peerDependency is not installed instead.

So for npm 3~6, yarn 1, and pnpm with auto-install-peers=false, typescript will not be installed when you are not explicitly depended it.

However, when typescript is depended by the main package, even in "devDependencies", it will be installed due to peer deps.

@voxpelli
Copy link
Collaborator

One could maybe avoid this by adding:

  "peerDependenciesMeta": {
    "typescript": {
      "optional": true
    }
  }

I would rather remove it completely though.

Showing which TS versions you support feels like something for "engines" rather than a peer dependency.

@sindresorhus What do you think about adding this?

"engines": {
  "typescript": ">=4.7"
}

Eg. tools like VSCode defaults to using their own version of TS anyway, so it should be metadata that can be read explicitly by such tools rather than be inferred implicitly by an installed dependency. (Sorry for not chiming in on the earlier issues)

One can use a tool like my installed-check to ensure that one exposes the correct needs of ones dependencies:

installed-check --engine-check --engine-no-dev

@OpportunityLiu
Copy link
Author

One could maybe avoid this by adding:

  "peerDependenciesMeta": {
    "typescript": {
      "optional": true
    }
  }

Then you have to install with --no-optional, and all optional deps will not be installed.

@voxpelli
Copy link
Collaborator

@OpportunityLiu Is that true for optional peer dependencies as well? Not just for optional dependencies?

@OpportunityLiu
Copy link
Author

OpportunityLiu commented May 20, 2023

@voxpelli

In fact, for pnpm@8.5.0, I've tried:

package.json

{
  "pnpm": {
    "peerDependencyRules": {
      "ignoreMissing": [
        "typescript"
      ]
    },
    "packageExtensions": {
      "type-fest": {
        "peerDependenciesMeta": {
          "typescript": {
            "optional": true
          }
        }
      }
    }
  }
}

.npmrc

auto-install-peers=false

and install with pnpm install --prod --no-optional, and typescript is still installed.

@sindresorhus
Copy link
Owner

Eg. tools like VSCode defaults to using their own version of TS anyway, so it should be metadata that can be read explicitly by such tools rather than be inferred implicitly by an installed dependency. (Sorry for not chiming in on the earlier issues)

Do any tools use engines.typescript. If not, I don't really see the point.

@voxpelli
Copy link
Collaborator

Eg. tools like VSCode defaults to using their own version of TS anyway, so it should be metadata that can be read explicitly by such tools rather than be inferred implicitly by an installed dependency. (Sorry for not chiming in on the earlier issues)

Do any tools use engines.typescript. If not, I don't really see the point.

Chicken and the egg problem – if no one publishes it then no one uses it and vice versa. If we think there’s merit to the original issue then we could add it to help solve that issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants