I have a project developed on node.js.
Development takes place on two different machines: one bit x32, on the other - x64. The problem is that some npm-modules have conflicts if they run in different environments.
For example, dNode. I installed it on a machine with 32 bit, but on the computer with the bit shch this module throws an error.
I can somehow control this process?
Add the dependencies to your package.json then use npm install on the target machine. If the module has special arch features, it will install it during the npm install. Do not ship the module with your codebase.
Related
I'm new on Angular, and I'm not able to run ng commands on WSL version 2.
I installed Angular CLI running:
npm install -g #angular/cli
After that I created a new npm project folder and a package.json running:
npm init
But every ng command returns:
/mnt/c/Users/xxxxxx/AppData/Roaming/npm/node_modules/node/bin/node: 1: This: not found`
I installed Node.js on Windows with an executable (so under PowerShell, everything works as expected). Am I wrong with this?
I installed Node.js on Windows with an executable before (so on PowerShell works), am I wrong with this?
Not, necessarily "wrong", but it's likely part of the problem. But you are certainly correct to question it and provide it as a critical detail in your post!
While WSL can launch Windows executables, keep in mind that those Windows executables (npm in this case) typically only understand Windows paths, processes, environment variables, etc.
npm on the Windows version of Node is a bit unusual, thought. It provides a Bash shell script, which is actually what is being called when you run npm under WSL. That shell script was originally designed for Cygwin and Git Bash, but I see that Node recently added checks in it for WSL as well. Before that, even (the Windows version of) npm itself would have issues under WSL.
But regardless of whether they've fixed npm to work under WSL, then you run into the next level of issues since Angular hasn't modified ng to detect when it is running under WSL.
Without having dug into the source code, ng is going to see that it is running under the Windows version of Node and try to use Windows tools and paths. In my test under WSL (using the Windows version of Node/npm), what seems to happen is that ng new project tries to start CMD.exe. Since it is running under the Windows version of Node, it naturally assumes that CMD.exe is available.
And it is, but starting CMD.exe from inside WSL will attempt to start in a UNC path (\\wsl$\<distroname>\path\to\current\project\dir or \\wsl.localhost\...). CMD doesn't support UNC paths, so it defaults to the Windows directory itself, and I get:
EPERM: operation not permitted, mkdir 'C:\Windows\project'
While you are getting a different error, to be sure, it's almost certainly related to this root issue.
To make a long story longer, see my advice in the question, How to organize programming languages and libraries in WSL and Windows 10.
To summarize it, when using development tools, either:
Use the Windows version of the toolchain (editor, commandline, SDK, tools, etc.)
Or use all-Linux versions of the toolchain.
Also, though, be careful with Node specifically. You can install:
The Windows version of Node for when you are using Windows tools
The Linux version of Node for when you are using WSL tools
But when you are running in WSL/Linux, make sure that the Linux version of npm and node appear first in the path, before the Windows version. This is, again, because of the fact that the Windows version provides that shell script. If the Windows version comes before the Linux version in your Linux PATH, then you will continue to have issues since the Windows npm will get called under WSL (as it is now).
Our NodeJS application should run on Linux and Windows servers. We have the following dilemma:
If we run npm i as our CI Build then we sometimes get errors due to differences between the developers laptop's NPM and the build server.
However, if we run npm ci then the build will presumably be locked to the platform of the developers laptop (Windows) and not work on a linux build server.
Maybe our assumptions are incorrect:
Do we need to build 2 versions of our app: one for each platform?
Does npm ci lock us into the platform of the developer's machine through package-lock.json?
Examples of builds working on developers Windows laptops and on Windows servers but not on a Linux server are apps like strapi or packages like sharp which compile stuff for the platform (.dlls for windows, godknowswhat for linux).
Apparently there is no portable way to create a portable node_modules folder, even if all dependencies are pure javascript ones.
I found this the hard way as it seems that npm created different scripts on Windows, like ones ending in .ps1, something that does not happen on POSIX platforms.
That means, that no way to track node_modules in git either.
Coworker and I are trying to figure out why compilation times are different. We have the same exact Dell Laptop 7030 model, same SSD, same hard drive, same memory, specs. Our task manager process look similar.
Corporate orders the identical model computers.
We are downloading from Angular Git Repository, with config and package json, with same node size memory.
Question is, Initial build between our laptops is 2 min compared to 8 min.
When we edit a single word in same file, his only takes 5 seconds to recompile, my takes 20 seconds.
Only programs running on the identical computer is Angular command ng serve.
Does anyone have ideas to resolve this issue, and slow compile time?
Is there anything I can change in my work station to the compile speed similar?
Attemped the solutions for all coworkers, still slow
We have same Node.js versions
updated from Angular 8 to 10 in Company Project Git Repo
tried npm cache clear
attempted Uninstalling and Reinstalling Angular and Nodejs
ScanDisk from Windows does not show errors on SSD drive
compared package-lock.json with coworker, they are the exact same, compared in source control diff
turned on Windows Defender Exclusion on the Angular Git Folder
Resources:
Angular compilation slow
How to speed up the Angular build process
Update:
Just noticed my laptop really stalls on styles.scss file at 48%
As you described enough, All the things are the same, whether node or angular versions, Hardware models, software and configurations. You also ensured that build pipelines are the same.
The only thing which comes to mind is a few difference in dependencies, yes the version mismatch inside node_modules packages. Considering that when you dont specify exact versions like ^x.x.x (aka semantic versioning) includes everything greater than the particular version in the same major range for dependency to be installed by npm or yarn. There's a tool named npm semver to show this. In this way, You have to check the installed packages versions too, by opening each one and looking inside package.json file. Specially for those which you think affect the performance like sass loader. Performance for each release may be different.
If you are running exactly the same codebase.
I would with a high degree of confidence say that it is
node.js or different npm versions that is the problem
try running
node --version
npm --version
yarn --version
to see which versions of them you have installed.
for angular 9 I would suggest running node 12, which is the current LTS (Long Time Support) version.
until node 14 which is also out now, but it's LTS release is not until october 2020.
I find yarn to be magnitudes faster than npm, so if you want a speed boost try running that if you haven't tried it.
Also Try clearing the npm cache, as mentioned per comments.
npm cache clear
I've written a custom node addon that works perfectly fine when running the 64 bit version of Electron.
I tried setting the architecture to ia32 and everything builds, but I get the not valid win32 application error, no matter what I do.
My environment settings are:
npm_config_disturl=https://atom.io/download/atom-shell
set npm_config_target=1.0.1
set npm_config_arch=ia32
set npm_config_runtime=electron
set HOME="C:\Users\myHome\.electron-gyp"
set VCTargetsPath=C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140
I have been building the addon by calling npm install.
Here's how I set my node to target 32 bit and install all packages in 32bit format. It works for me. You may try.
npm set npm_config_arch ia32
npm clean-install --arch=ia32
The first command set the node environment to 32bit.
The second command re-install all the node packages that are 32bit compatible.
I was trying to compile for windows from mi Mac and I had that problem too, but after some readings I figured out how to proceed, and after all I can say that I got it. Yesterday I spent all day setting up a windows virtual machine in my (other) Linux laptop (I used my linux laptop just because my mac was exhausted in storage...). I was having too a problem with the preloadScript from electron main process in windows, Cant found the script, it was solved too.
Anyway, I think the library node printer from #tojocky is well maintained, in other hand in the electron-builder documentation they say that you should compile in native for natural reasons. Once you will have it, you'll see that it's a cleaner and pragmatic solution ...
This was my entire process, I hope it helps to someone having the same issue:
Get VirtualBox (or Parallels but is not free)
Get iso for W10
Create a VM with this W10 iso, and you should give to this VM some storage (because some dependency that you'll need to compile), I have assigned 60gb to this VM
Once I had that VM running, I just installed in that machine Visual Studio 2017 (with their build-tools included, it's necessary)
And then, I used CMD to make the rest
Install NodeJS (and NPM, but it comes with)
Install node-gyp globally
Install Python 2.7
Clone your project from git (in my case)
npm i (in your project), you should have as npm dependency in your package.json the module electron-builder of course. (here I had some troubles because when node-gyp tried to rebuild printer to generate the binary for windows it was failing, this was because it was imposible to find the python executable, so if you face this problem you should add it like:npm config set python "c:\Python27\python.exe" in my case )
Then try again npm i and Voila!
After all, you should make the build using electron-builder, in my case my npm script command was build --win --x64 but you can use the --ia32 flag as well for 32bits
We are behind a firewall.
We have a self-hosted central npm repository, that doesn't have all the packages (most, but not all).
It seems the grunt build process (to compile from source) relies on phantomjs to be built via npm. I have phantomjs 1.9.2 built from source and available, but the process specifies that it needs to be installed via npm to work.
My goal is to build so I can use the IDE in my environment. There is a .app, and a .msi available for Wndows and Mac, but for Linux I have to compile from source (we have a .deb, but I'm on CentOS).
Any help is appreciated.
It looks like you don't actually need PhantomJS for building Brackets -- I see it's a dependency in the package.json, but I don't actually see a mention in the Brackets source code where it may be called.
So could you just try building Brackets without having PhantomJS installed and see if it works?