Crashes when the source file doesn't physically exist
See original GitHub issueAffects: v1.8.3
When a file in the stream doesn’t exist on disk (quite a common scenario in a Gulp pipeline), gulp-header crashes
because the path can’t be found.
I tracked the issue down to https://github.com/tracker1/gulp-header/commit/7feb21151e9101baa47a5ce61d3d6dbc7b975b08#diff-168726dbe96b3ce427e7fedce31bb0bcR38
I guess it should be enough to simply check for existence of the file:
if (fs.existsSync(file.path) && fs.lstatSync(file.path).isDirectory())
works for my use case.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:16
- Comments:21 (2 by maintainers)
Top Results From Across the Web
Crash when running application due to existence of ...
Crash when running application due to existence of unexecuted code in source file - c++ ... I'm working on a pretty tricky problem...
Read more >HELP!!! Quicktime Crashed and Perminanlty Deleted Files ...
I was trimming a movie file in quicktime when the application crashed. Upon crashing I saw my file get deleted from my computer....
Read more >Top 10 C++ header file mistakes and how to fix them
The problem is that the source files that #include the header file may or may not have the MACRO defined. This can be...
Read more >Crashes - Android Developers
An Android app crashes whenever there's an unexpected exit caused by an unhandled exception or signal. An app that is written using Java...
Read more >No log file after node crashes - ROS Answers
log . However these files do not exist, since the content of the folder is: . ├── map_node ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Merge and deploy
1.8.4
, no need to worry about the commit history being rebased, just fix it.There are a large number of broken builds out there and you’re going to end up with a large number of users pinning their version at
1.8.2
, meaning any critical fixes will no longer be deployed to these installs.I hate to state the obvious, but this is rapidly becoming a very urgent issue. Any chance this will be patched by Monday?