I have configured storybooks(6.1.14) for angular (11), I am currently importing mdx file into CSF(.stories.ts). Stories are compiling fine but when I run jest (for snapshot testing), it throws error
Cannot find module './SampleComponent.mdx' or its corresponding type declarations.
Related
im using nextjs with prisma ,and my application is published on vercel, and today i changed my prisma Schema and generate and migrated the changes and for some reason when im in devlopment the prisma controllers works perfect,
but when i upload my application to vercel im getting error on build, and I'm pretty sure the problem is that vercel doesn't recognize the changes I made to the schema bec the error im getting is realted to the changes that i did to the schema.
i tried to generate and migrated again and stil it dosent worked.
and this is the error im getting:
Type error: Type '{ todoTypeTitle: string; }' is not assignable to type 'Enumerable | undefined'.
Object literal may only specify known properties, and 'todoTypeTitle' does not exist in type 'Enumerable'.
Your build script should include npx prisma generate command to ensure that your schema changes are correctly reflected in the generated Prisma Client.
Here's an example that demonstrates how npx prisma generate command can be a part of build script. In the example migrate deploy is also the part of the script, you can omit it if you are not using Prisma Migrate.
I'm refactoring my React app to Type Script. In each component Type Script gives me this error
Cannot find module './.module.css' or its corresponding type declarations
How I can resolve this error without webpack(if this possible)?
I have a project setup where I have a web app that rely on few Firebase SDKs that is Webpacked and served via webpack dev server.
From what I could gather without getting into too much details is that there is a final dependency that have both general index, and es2017 index files
there are intermediate dependencies that also have both, like the app and some that have only es2017 for example the messaging, and some only general index files.
The problem I have is that, and I have debugged for a very long time, from my application level when I import an intermediate dependency in different files, in some cases it takes the general index file, and in some the es2017 of the same library.
So in the error stacktrace here I am trying to initialize the messaging service of Firebase: (ignore for a moment the missing promise reject)
at Provider.getImmediate (index.cjs.js:153) // in component lib
at Module.getMessagingInWindow (index.esm2017.js:1155) // in messaging lib
at new MessagingWrapper (MessagingWrapper.js:76) // in my application
at FirebaseSession.push.56916.FirebaseSession.getMessaging (FirebaseSession.js:96)
at PushPubSubModule_Class.<anonymous> (PushPubSubModule.js:118)
at step (PushPubSubModule.js:63)
at Object.next (PushPubSubModule.js:44)
at fulfilled (PushPubSubModule.js:35)
When the messaging module is initially loaded it also accessed the component lib and uses the correct es2017 index file, but at a later point when I am trying to actually get the instance of the Messaging service it goes to the other general index file.
in all cases I use the import the same as in import {somthing} from "#firebase/messaging"
I never really had to worry about these things and might miss something fundamental, but this feels like a webpack bug in predetermine which module to load from the nested lib...
do you know of a way I could FORCE webpack to resolve es2017 index file?
or should I open a bug?
More details:
This is the transpiled code of my MessagingWrapper file:
line 71: goes to the correct es2017 index file in the messaging lib and the correct es2017 in the component lib
where as line 76: goes to the correct es2017 index file in the messaging
line:
and here line 1155: actually goes to the firebase/app lib es2017 file to resolve the provider, comes back to line 1155 and then call to getImmediate which ends up in the general index file in the component lib, as you can see below:
How do I fix this?
#firebase/* packages are internal and you shouldn't be importing them within your code as warned on each of their npm directory listing. As you encountered, this can lead to issues with module resolution as you essentially skip the internal setup steps by accessing the internals directly.
Instead, use the public API interfaces via firebase/* (for the modular SDK on v9+ or legacy SDK v8 and lower) and via firebase/compat/* (for the legacy SDK on v9+).
I'm following this tutorial that uses Ionic framework and Firebase backend to create an image recognition app https://www.youtube.com/watch?v=taPczl94Eow
For this line:
import * as vision from '#google-cloud/vision'
I keep getting the error:
Could not find a declaration file for module '#google-cloud/vision'.
'/Users/Private/Workspace/project/functions/node_modules/#google-cloud/vision/src/index.js' implicitly has an 'any' type.
Try `npm install #types/google-cloud__vision` if it exists or add a new declaration (.d.ts) file containing `declare module '#google-cloud/vision';`
What should I do? I already installed it properly. I also enabled the API from the GCP platform and followed their instructions
I was also having the same problem, so I had to replace this line:
import * as vision from '#google-cloud/vision'
For this line (it works with Typescript):
const vision = require('#google-cloud/vision');
I hope this works for your case.
I'm trying to deploy a function in firebase cloud functions to be triggered when a new file is uploaded in the storage.
I've included the google-cloud/storage lib to manage some download but it seems there's an error in the lib preventing me to deploy :
node_modules/#google-cloud/common/build/src/service-object.d.ts(72,45): error TS8020: JSDoc types can only be used inside documentation comments.
node_modules/#google-cloud/common/build/src/service-object.d.ts(72,45): error TS8028: JSDoc '...' may only appear in the last parameter of a signature.
node_modules/#google-cloud/common/node_modules/google-auth-library/build/src/auth/oauth2client.d.ts(291,55): error TS1039: Initializers are not allowed in ambient contexts.
Does anyone face the same issue ? any workaround ? downgrade lib to older version or newer for TypeScript ?
Thanks,
Nanex