We are using Gulp with browserify, and I am having a problem diagnosing an error. Browserify runs, reporting no problems, however, many of the scripts that should have been concatenated into my output js file are missing.
We have found that this can happen if we are missing an npm package (if we need to run npm install), or if there is something wrong with an npm package. The past couple of times it has happened, we have been lucky in that we had only just added 1 package and so we immediately knew where to look.
Now, I have it failing on a dev machine (by fail, I mean that my output .js file is 1/10th the size it should be an missing many js files, but no errors reported). I am not sure which package it is failing on, and I am getting no diagnostics.
I tried hooking .on('error') as described here: https://stackoverflow.com/a/24817446/67038, but there was no additional output.
The output from the Visual Studio Task Runner Explorer looks like this:
[18:17:21] Using gulpfile C:\git\...\Gulpfile.js
[18:17:21] Starting 'browserify:local'...
[18:17:24] Finished 'browserify:local' after 2.63 s
[18:17:24] Starting 'build:local'...
[18:17:24] Finished 'build:local' after 31 ms
Process terminated with code 0.
What can I do to get additional information from Browserify? Is there some sort of logging that I can turn on?
The problem you experienced was caused by the tsify plugin.
Prior to version 1.0.4, there were a number of path-related bugs that could result in empty modules being emitted without any errors being reported to Browserify. These bugs have been fixed and errors are now emitted to Browserify in situations that would have previously resulted in an empty module.
Related
Hi so we have something interesting happening in our builds.
Nothing regarding the gulp build script changed from our side for one of our projects. But suddenly today when we try to do a pipeline build on one of our repositories we get the following stacktrace error:
Error: Cannot find module './dist-tools/transform.js' from '/opt/atlassian/pipelines/agent/build/node_modules/aws-sdk'
at /opt/atlassian/pipelines/agent/build/node_modules/resolve/lib/async.js:128:35
at load (/opt/atlassian/pipelines/agent/build/node_modules/resolve/lib/async.js:147:43)
at onex (/opt/atlassian/pipelines/agent/build/node_modules/resolve/lib/async.js:172:17)
at /opt/atlassian/pipelines/agent/build/node_modules/resolve/lib/async.js:13:69
at FSReqWrap.oncomplete (fs.js:152:21)
Has anyone come accross this before? (we are using node 10.17 for our builds)
We tested the same code from our local builds and get the exact same issue. It seems that something in the aws-sdk package changed?
Since this error suddenly appeared this morning, we looked at our aws-sdk package and updated it to the latest version (2.643.0), but we still get the same error. No code that uses the aws-sdk package has changed.
Also seeing this as of this morning. I find this somewhat sus (adding dist-tools to npmignore).
https://github.com/aws/aws-sdk-js/commit/98c40e64cb7d60927c6a0cec49592fc1fcaa59d7
I wonder if pulling the package directly from GH would resolve.
UPDATE:
I've got a convo going on over here about this https://github.com/aws/aws-sdk-js/issues/3159
We downgraded to the previous version and our issue went away.
I am not sure where to start looking for the issue here.
I recently updated from angular 5 to angular 8. The application runs fine after the update. I don't know if this is related.
All of the sudden, my Node JS scripts stop seemingly at random. Sometimes they run, usually they don't. This is any script.
By "Stopping" I mean the console, mid execution, leaves the last line it wrote up, and on the next line, I am able to write more commands.
Example:
C:\location\> npm start
ng serve --aot
** Angular Live development server is listening on .....*
12 % building 22/23 modules 1 active ...somefile.ts
C:\location\>
There is no error, even when I run --verbose. Also, if I have multiple windows up or multiple servers running, they all stop at the same time. It is happening regardless of the application or package, including http-server, Angular, and installing dependencies.
I couldn't find anything related online. Has anyone ever seen this?
Update:
The issue is caused by my lack of CPU.
I thought I fixed it by updating, but that didn't work.
----------- (previous reply, not a solution)
It appears some of my installed dependency versions conflicted with package.json. Basically something did not fully update as expected.
I resolved the issue by running npm install.
I have an Angular 2 application, running in Electron and using Knex for database interaction that has successfully compiled and run several times over. After several edits, I attempted to run the application locally and received the error ReferenceError: "yexecutor is not defined".
Googling the error yielded no results. I have gradually commented out every line of custom code written by me and still the error occurs. I've even rebooted my rig thinking, perhaps, Node was just acting up. After a reboot, I'm still getting the error.
After commenting all of my own code, rebooting and finally dying and coming back to life to try again, I remembered I was investigating the source of some of the packages I had installed. So, I decided to try deleting the node_modules directory and execute an npm install.
A few minutes later, I'm back to a successful compile!
Steps to solve:
Delete node_modules
npm install
I must have fat fingered the keyboard while meandering through the packages! That, or my cats decided to become contributors.
Viola!
I have written a Electron application using Node, Electron Boilerplate, and phantom. It works perfectly fine for me on my linux machine, I copied the source over to Windows 10, and ran with npm start, and all goes smoothly.
However, when I try to build the application with the boilerplate module using npm run release, things go a little less smoothly. I can install and open the application just fine, but when I click the button that activates the phantom module, the windows goes all white and nothing happens. I was able to logs some errors with the dev tools.
First, I have:
C:\...\dist\win-unpacked\resources\app.asar\node_modules\phantom\lib\phantom.js:361
Uncaught (in promise) Error: Error reading from stdin: Error: write EPIPE(…)
I did some research into similar issues, namely here, and it seems to me the issue is starting the child process, PhantomJS, with the npm module phantom. Originally, I was using a WPF application I wrote in C# to start the process, and that worked just fine. This leads me to believe that the phantom module is the culprit.
So I tried swapping out the npm phantom module for horseman, but got similar results:
Unhandled rejection HeadlessError: Phantom immediately exited with: 4294967295
at ChildProcess.immediateExit (C:\...\dist\win-unpacked\resources\app.asar\node_modules\node-horseman\node_modules\node-phantom-simple\node-phantom-simple.js:153:23)
at ChildProcess.g (events.js:286:16)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at Process.ChildProcess._handle.onexit (internal/child_process.js:204:12)
Here is a shot in the dark. I am not positive this will solve your issue but here it goes:
GYP and miss-matched binaries
Phantom and many other node modules use binaries built for the specific OS that it will be running on. Sometimes in your npm log files you will see references to node-gyp. Node-gyp simply helps to build native add-on's in node modules. When the binaries are built they are usually built against, among others, three main parameters, the operating system, cpu architecture and version of node that is doing the installation.
I think you need to rebuild phantomjs to the version of node Electron is using. Most of the time the node version you have installed on your machine and the node version running in Electron are not the same. Electron does its best to keep up, but there is always a little lag because of the amount of work and testing required to keep up-to-date.
When you install phantom by running npm install phantom it will assume it needs to install or build the binaries for the node version your machine is using. Then when your Electron app tries to run phantom it tries to call the binary of the Electron's node version. When it isn't there the child process immediately exits with an error.
How to fix
Luckily, there are other people out there that have figured out how to fix this issue and have created a great tool to help generate the correct binaries.
Enter electron-rebuild:
https://github.com/electron/electron-rebuild
Electron-rebuild can be run in the command line, and it will rebuild all of your native modules to the version of Electron your project is using.
To install:
npm install electron-prebuilt
To use (in Windows):
.\node_modules\.bin\electron-rebuild.cmd
This should be enough to put the correct binaries in the right place.
Other thoughts
Sometimes you can use a package that uses a dependency called node-pre-gyp. E.g. sqlite3. There is a known issue I ended up running into when trying to rebuild my packages for Electron. Basically, in order to avoid this issue (if you run into it) just append --pre-gyp-fix to the above command.
Tangent for those who run into the pre-gyp-fix issue
One more thing on the pre-gyp-fix: If one or more of your dependencies depends on one of the modules that need the pre-gyp-fix then they will be looking for the binary in the wrong place even if they are running in Electron. All of the pre-gyp binaries are stored in a folder similar to this:
.\node_modules\sqlite3\lib\binding
In my current project I have three folders here, one for Electron-v1.4, and two for node-v46 and node-v50. (hack alert) In order to have sqlite3 work with my other dependencies I copy the binary found in the Electron-v1.4 folder and put it in both node-v* folders. That way when running in Electron, all dependencies are running the correct binaries even though they are looking for them in the wrong place. (end hack alert)
Conclusion
There is no way I can be sure this has anything to do with the issue you are seeing. But it is worth a shot to see if it fixes your problem. If not then at least I hope I can help someone else experiencing the same issues I ran into.
I hope I'm close with this, it's starting to get really frustrating.
I've asked this before: Is it possible to setup Gulp in a distributed fashion?
...but I'm still not quite able to get it to work.
I've created a gist with the two files I'm working with.
my-gulp is installed via npm.
It's hitting my-gulp/gulpfile.js just fine, but I'm getting the following output:
> gulp
READING MY-GULP/GULPFILE.JS
CWD: /Users/will/projects/my-app
[15:49:11] Using gulpfile ~/projects/my-app/gulpfile.js
[15:49:11] Task 'default' is not in your gulpfile
[15:49:11] Please check the documentation for proper gulpfile formatting
If I had to take a guess, it's something to do with the cwd being the root of the app, however I would assume it would error long before making an attempt to load a task (this fails when attempting to run any task, btw, not just default).
Does anyone have any ideas? I'm really at a blocker here :(.