I'm seeing the mentioned error, with stack trace below
Error: Cannot find module 'src/auth/guards/jwt-auth.guard'
Require stack:
~/Documents/Code/nestjs-passport-learning/dist/src/user/user.service.js
~/Documents/Code/nestjs-passport-learning/dist/src/user/user.module.js
~/Documents/Code/nestjs-passport-learning/dist/src/app.module.js
~/Documents/Code/nestjs-passport-learning/dist/src/main.js
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:939:15)
This error makes no sense, though, as the user module/service is not looking for that auth file at all. It was at one time, but I removed it while trying to debug the error. It seems like something internal to node itself is bugged and still looking at an outdated version of the code.
What happened:
Code was working/running perfectly
I decided to add "UseGuards(JwtAuthGuard)" to one of my user.service methods
At the same time I decided to setup debugging, so I added a launch.json file
Tried running the code. It built, but had a ton of "can't find bla bla" errors at runtime.
I stopped the app and figured the error was do to me not exporting the class in auth.module and not importing the AuthModule in UserModule(which was true).
I fixed that error, and restarted
Now getting the error message above
I removed the "UseGuards(JwtAuthGuard)" and all imports to it and AuthModule import in UserModule, as well as the launch.json file(ie revert back to exactly the code that was running perfectly 10 minutes earlier)
Still getting the same error(despite there being nothing in the user module that looks for it.
Why is user.service.ts still looking for that jwt-auth.guard.ts file?
Other things I've tried:
removing the "jwt-auth-guard.ts" file itself
checking out an earlier version of the code where "jwt-auth-guard.ts" hadn't even been written yet
restarting my machine
Nothing worked, no matter what, I get that same error, despite the code not being any different the code that worked.
link to github repo
Any help would be greatly appreciated, as I have no idea what's going on, and no idea what to google to even try to fix this problem.
Alright, so after some fiddling in my application, I tried renaming my 'dist' folder to try it, and it worked! So I guess the "caching" was due to the dist folder.
Peace and happy coding!
Related
I have managed to build my angular app out as a dev build. I haven't done it as a production build yet as it gives me a few errors and i just need to test the dev build.
The dev build process goes fine, no errors or anything. I then use the files from the dist folder in a nginx docker container to host the files.
The problem is nothing is displayed but a white page and in the console i get an error saying 'Uncaught TypeError: Cannot read property 'id' of undefined'. The full message below doesn't seem to point to anything i have written and i've spent several hours searching online but can't find anything on this problem.
I've tried a few different things such as running 'npx ivy-ngcc' which i read manually compiles some stuff. Is there anyway i can get more details on the error to see if it's something i have done?
UPDATE
So i have restored the line that i commented out in main.ts as mentioned in the comments below. I have also tried 'ng build --aot' as suggested which presents me with a series of errors that all seem to relate to devextreme components that are used. I find this strange as i started the project with the devextreme angular starter project from github.
i get messages such as:
'dx-scroll-view is not a valid HTML element'
'node_modules/devextreme-angular/ui/drawer.d.ts - error: appears in
the NgModule.imports of SideNavOuterToolbarModule, but could not be resolved to an NgModule class'
If you go in the devtools and click on Sources, "Don't pause on exceptions" and check "Pause on caught expecptions" and continue until you get the "id error" you will find what module the error is thrown. In my case was a third party library called 'ngx-card/ngx-card' and it's module was the cause of the error (CardModule). Hope this will help find at least the cause of the error
I managed to solve the problem by disabling ivy in the angular compilation options. As soon as i did that it worked building both dev and production versions and is now working perfectly within Nginx.
Thanks to everyone who offered help :)
In tsconfig.json of your Angular project, put this to disable Ivy, the new Angular template engine
{
...
"angularCompilerOptions": {
"enableIvy": false
}
}
Typically, if it's not something that you've written, it tends to be an issue w/ your implementation - i.e. "Visiting a food vendor and ordering a food item they don't provide".
I know it's not a specific answer, but ensuring that you have appropriately configured things in your app.module would be a good first step. Perhaps attempting to build w/ AOT will also give you some more verbose failures that stem from attempting to build out.
Hopefully this helps another poor soul.
To anyone using devextreme, make sure you update your version to at least 19.2.5
https://github.com/DevExpress/devextreme-angular/issues/975#issuecomment-580172291
Starting with version 19.2.5 we support the IVY compiler.
I had the same issue and fixed it by changing from
loadChildren: './app/page/account/account.module#AccountModule'
to
loadChildren: () =>
import('./app/page/account/account.module').then(
(m) => m.AccountModule
)
in app-router.module.ts
The root cause of your error is very likely to be a module that you needed to load explicitly but didn't, or a circular reference in your own modules. Rodrigo has a good answer but to be more specific, you need to find the registerNgModuleType function in Angular's core.js and set a conditional breakpoint on the first line. The condition should be !ngModuleType || !ngModuleType.ɵmod. (You can set a conditional breakpoint in most modern browsers by right-clicking the line number.)
Once you've paused execution just before the exception happens, you can look at the value of ngModuleType if it's not undefined, or walk up a frame or two in the scope and see what the value of imports was.
For me, this issue occurred while using Storybook.
The reason it happened was because of the way I was precompiling the node modules. I was doing:
Incorrect
ngcc --properties es2015 browser module main --first-only
Correct
ngcc
Using this approach fixed it
I am a new to Node JS. I have included a module via npm install '<module_name>. It was built correctly and there was no errors. Now, I wanted to debug it, so I placed a few console.log('some text') in code blocks of the module to see if the code by passes that line. Anyway, none of the log statements were displayed.
I am wondering if I have to compile or something the modules after adding the log staements. Am I missing something here.
Your console.log statements are not being run, this could be caused by many things.
Assuming you have added the console.log statements to the module code in the node_modules directory of your app..
does the module have src and dist directories and you have not edited the code that is actually being run? (this relates to needing to recompile, but editing the actual code that the module is running will be quicker and easier)
if this is in a server or long running script it will need to be restarted to load the changes
is this in a browser which might be caching the code (turn off browser cache)
is the code where you added the log statements actually being hit?
I would make sure I had a console.log statement in a part of the code guaranteed to be hit, just as a sanity check.
For anyone coming here in the future, try console.error instead of console.log. For some decided reason or another, log was being overriding by the library I was monkey fixing. Took me way too long to find the culprit.
NOTE: Here is an example repo with the problem.
When I run ./gulp js, the process works (creates the expected files on the file system), but the task never completes... just hangs indefinitely:
ss http://zc.d.pr/4C9U/3GG90rpz+
I figure I'm not returning something somewhere, or invoking a callback correctly, but after hours of tinkering, head-banging, and Googling, I haven't found a solution.
Can someone help me out here?
If it makes a difference, I'm currently using node v4.1.0. All other dependencies and versions are in the example repo linked above.
EDIT: Original inspiration for this gulp recipe came from https://truongtx.me/2015/06/07/gulp-with-browserify-and-watchify-updated/
However, I couldn't get transform to work as that author suggested, which led me to https://github.com/substack/node-browserify/issues/1198#issuecomment-89948202
Of course—as it always happens—I think of something new to try just after I post to SO and it appears to work.
doh http://zc.d.pr/11uMa/5gghjbCx+
You can see my full changeset here: https://github.com/neezer/gulp-browserify-hanging-task/commit/8156e182c04c2e76c5739e31f5a6e417dda01b70
TL;DR Basically I tried the suggestion in the last comment on the aforementioned issue from my question, where I pass the file object itself to browserify instead of the file path, and lo-and-behold, the task finishes now.
I don't pretend to know why that fixed the issue, so if anyone would like to explain, I'd love to learn. ;)
Okay so my MFC application was working fairly well until I cleared the application from the system registry. Now I am unable to run the program. Whenever I try running the program I get an exception. Checking the stack I noticed that CreateEx in LoadFrame for CMainFrame was crushing. This crash occurs when ProcessShellCommand is called in the derived CwinApp of the application.However, I have not been able to pinpoint the exact cause of the crash. I have a hunch it might have something to do with the loading of resource but I don't know exactly how. I have checked the .rc include file and it looks fine to me. I just don't understand how clearing the registry could cause such a mess. Been at it for the past 4 hours.
So basically I am asking if any of you have faced this problem before, and how did you managed to fix it without starting right from scratch? I am not sure of the exact part of the code I should put here to clarify my question so I hope this is clear enough.
Thanks
I have an app that has been running fine on the iPhone simulator for some time. Recently, I decided I wanted to re-use the data model and related classes in another project - so I dragged them from this project window to the other then told Xcode not to copy, just to make references. At first this didn't work so I jumped through a number of hoops to try to fix it (I may be asking more about that in another post). After all this, I re-compiled and tried to run the original app -- and it's not working any more. On further investigation, I discovered that when I re-compile the original app, I end up with a bundle that contains a .momd package but it contains only a Versioninfo.plist file - no .mom file, no .omo file like I'm expecting to see. I don't recall making any changes to the original app. I don't get any warnings. I just get an incomplete .momd package (and, not surprisingly, my app now crashes).
What's going on here?
BTW, the app now crashes with this message:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '* -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
Which I get when executing this line of code:
self.productRegistry = [[UIManagedDocument alloc] initWithFileURL:self.productRegistryURL];
I figured this out by looking more closely at the file locations in the project directory using Finder. In the Xcode window, everything looks normal but in the actual project directory I found that the .datamodeld package had ended up at the top level of the project directory -- at the same level as the project package itself. Xcode apparently did not like this but unfortunately it did not complain -- it just created a partial build output. Once I moved the .datamodeld package into the same folder as the rest of the project's code, everything worked just fine.
This would appear to be just a quirk. I would expect that Xcode would either see that all is well and build correctly OR it would see that things weren't quite as they should be and fail. In this case, it did not build correctly but was silent about it.
Hope this answer helps someone else someday.