Jackie McDoniel
Jackie McDoniel
@probil I just helped someone with a very similar problem, in your test are your providing the following code to your `Test.createTestingModule()`? ```typescript beforeEach(async() => { const module = await...
Go for it. I'll be happy to make adjustments where necessary
> a year has passed And no one has made a PR for it. Would you like to @AarNtyon?
To be clear, this isn't related to NestJS directly. Only to the Typescript types. [A minimum reproduction repository without NestJS can be found in my comment here](https://github.com/fastify/csrf-protection/issues/133#issuecomment-1533778743)
Sure enough, it's kind of hidden in this line as well: https://github.com/fastify/csrf-protection/blob/0b0463525705ed712e4c21b33fa7c4b3ae7ee44b/types/index.d.ts#L40 I can confirm that adding `csrfOpts.hmacKey` does remove the type error.
When you're ready to add this to the deploy pipeline, add a changeset by running `pnpm changeset` and following the wizard. Initially set the package version to `0.0.0` and choose...
Ignore the CI failures, it's cause of the branch's origin Do you have any tests for this package as well? To show it's working as intended?
I want to point out that if you take Nest's default `.swcrc` .swcrc ```json { "module": { "type": "commonjs" }, "jsc": { "target": "es2021", "parser": { "syntax": "typescript", "decorators": true,...
Added to #1565 will be a part of the 5.0.0 release