I have a feeling this problem might be related to the project's tsconfig maybe, but here it is:
I have a library package that uses redux-toolkit for generation action creators. That library is a dependency in my project (which is a react-native project. -- v.0.63.4
of RN).
The problem comes with actions that are created with the prepare()
function added. My project complains about the typedef in the types.d.ts
file and so everything is broken when i try to do any work with action.match()
etc in my middleware.
Example action in the library:
export const myAction = createAction('myActionNameHere', function prepare(title: string, data: Map<string, string>) { return { payload: data, meta: { title, }, }; },);
here's how that action's type def looks in the d.ts
file:
export declare const myAction: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[title: string, data: Map<string, string>], Map<string, string>, "myActionNameHere", never, { title: string;}>;
To my eyes, that def looks correct. But when I use that action in my middleware and try this:
if (myAction.match(action)) { // ...stuff here}
I get red errors under match
because it thinks myAction
is still just a generic Action
.
It thinks that since it can't parse the type def file correctly.
When I open the d.ts
file for the action, VSCode is complaining that:
Generic type 'ActionCreatorWithPreparedPayload<Args, P, T, E, M>' requires between 2 and 5 type arguments.ts
All other actions that use createAction()
that don't use the prepare function export in a way that my compiler/linter isn't complaining about. It's just the ones with the prepare
function that are the problem.
That same d.ts
file, when opened in the library workspace where it was defined doesn't show the errors. Which makes me think it's something to do with the tsconfig or maybe even the fact that the library is using ESLint for typescript but my project that imports the lib is older and still uses TSLint.
Here are the tsconfig.json
files for each:
library project tsconfig.json
:
{"compilerOptions": {"target": "es5","module": "esnext", "jsx": "react-native","lib": ["esnext" ],"declaration": true,"sourceMap": true,"outDir": "./dist","strict": true, "alwaysStrict": true,"allowUnreachableCode": false,"allowUnusedLabels": false,"importsNotUsedAsValues": "error","noUnusedLocals": true, "noUnusedParameters": true, "noImplicitReturns": true, "noFallthroughCasesInSwitch": true, "moduleResolution": "node","baseUrl": "./","paths": {"proj-types": ["./src/index" ] }, "esModuleInterop": true, "skipLibCheck": true,"forceConsistentCasingInFileNames": true }}
My react-native project's tsconfig.json
:
{"compilerOptions": {"allowJs": true,"allowSyntheticDefaultImports": true,"esModuleInterop": true,"isolatedModules": true,"jsx": "react-native","lib": ["es2017" ],"module": "commonjs","moduleResolution": "node","noEmit": true,"plugins": [ {"name": "typescript-tslint-plugin" } ],"resolveJsonModule": true,"skipLibCheck": false,"strict": true,"target": "esnext" },"exclude": ["node_modules","babel.config.js","metro.config.js","jest.config.js" ]}
Any ideas what config option might be the issue? The RN project is quite large and is an older project that has been upgraded as RN went. Started it 2 years ago on RN .61 maybe.
I was planning on doing the TSLint --> ESLint migration soon, but wasn't rushing. If that's the issue, then maybe I'll bump that up.