I'd like to report an issue with the review flow. I believe typescript-bot
requested a re-review unnecessarily in my PR: DefinitelyTyped/DefinitelyTyped#50378
What happened:
doberkofler
) accepted.eps1lon
) requested changes.typescript-bot
requested that Maintainer 1 re-review and accept the changes.Step 6 seems like a mistake, since Maintainer 2 has already accepted the latest changes.
Typescript Bot issue:
typescript-bot
keep saying "I'm ready to merge this PR...", I commented "Ready to merge" as requested buttypescript-boot
respond again with the same message "I'm ready to merge this PR...". This seems to go in a loop and I can't merge the PR.The bot seems to be broken here?
Tried again and the PR is merged now. All good
Hello everyone!
I'm having a headache trying to solve a problem with @types:
I've forked a repository which is carbon-components-react
to add custom components to it.
Now when I'm importing the components from the forked library (which is on a self-hosted npm registry), I receive the nasty error:
Could not find a declaration file for module '@graphite/components-react'. 'c:/Users/my-name/projects/react--test/node_modules/@my-lib/components-react/lib/index.js' implicitly has an 'any' type.
Try `npm i --save-dev @types/my-lib__components-react` if it exists or add a new declaration (.d.ts) file containing `declare module '@my-lib/components-react';`ts(7016)
I can easily make this error go away by adding a index.d.ts
in a my-library__components-react
folder with a declare module '@my-library/components-react'
and editing the typeRoots
in the tsconfig.json
.
While this allows me to use my components, I'll never be able to use the right types from the original @types/carbon-components-react
npm package.
How could I solve this issue?
export function Cat(props: React.HTMLAttributes<HTMLDivElement>) {
return <div {...props}>cat</div>
}
getting this error:Types of property ''aria-relevant'' are incompatible.
Type '"text" | "all" | "additions" | "additions removals" | "additions text" | "removals" | "removals additions" | "removals text" | "text additions" | "text removals" | undefined' is not assignable to type '"text" | "all" | "additions" | "additions text" | "removals" | undefined'.
Type '"additions removals"' is not assignable to type '"text" | "all" | "additions" | "additions text" | "removals" | undefined'.ts(2322)
Omit<React.HTMLAttributes<HTMLDivElement>, 'aria-relevant'>
Curious if anyone has had issues using @types/karma-mocha-reporter
with @types/karma
. I just recently upgraded to the latest version of karma
and @types/karma
and see some new ts compile errors in my karma.conf.ts
file. (All on the latest version of typescript)
Argument of type '{ files: string[]; frameworks: string[]; reporters: string[]; mochaReporter: { colors: { success: string; info: string; warning: string; error: string; }; symbols: { success: string; info: string; warning: string; error: string; }; showDiff: boolean; }; ... }' is not assignable to parameter of type 'ConfigOptions'.
Object literal may only specify known properties, and 'mochaReporter' does not exist in type 'ConfigOptions'. ts(2345)
From what I understand @types/karma-mocha-reporter
overloads the 'karma'
module and adds the mochaReporter
field to the ConfigOptions
type, but that doesn't appear to work anymore with the same tsconfig file.
@peterblazejewicz , it looks like you are the author of the @types/karma-mocha-reporter
plugin, would you have any recommendations to move forward or how I could send out a fix?
@types/karma-webpack
except its for properties webpack
and webpackMiddleware
.
any
or unknown
just to make TypeScript compiler complain if anyone tries to use that private?@types/node
v15, but all them failed.@types/rdf-js
). However, we want to move these typings to @rdfjs/types
but have concerns about breaking user's TS projects that use @types/rdf-js
. I believe the best approach would be to publish a new minor version of @types/rdf-js
and then immediately deprecate that version so that user's can see the deprecation notice and migrate their dev dependency to the new package location.
@types/
org ourselves, so presumably this approach would have to involve a DT maintainer.
Disclaimer: I'm also rdf-js contributor
hey @blake-regalia I think deprecation handled by the DT's removal process. once we remove a package, it will publish a version and deprecate
Hi. I've added definitions for few packages with dependencies on each other.
Example: Package B depends on Package A and use most of types in Package A.
Now I have 3 choices:
Which one will be correct?
JavaScript heap out of memory
- but I have no idea why that would happen.