My question is similar to an existing one, but I'm using webpack and thus don't even have a "node_modules" directory.
I've still tried the following environment variable settings without success:
NODE_ICU_DATA: 'node_modules/full-icu'
NODE_ICU_DATA: '/var/task/node_modules/full-icu/icudt58l.dat'
NODE_ICU_DATA: '/var/task/node_modules/full-icu/icudt60l.dat'
All without success, the lambdas simply refuse to start and a log message is show in CloudWatch:
/var/lang/bin/node: could not initialize ICU (check NODE_ICU_DATA or --icu-data-dir parameters)
I found very little about this problem on Google, which seems curious given that it should concern so many that are building internal apps on AWS lambda.
Make sure you're deploying the correct .dat file version into the directory defined by NODE_ICU_DATA. In my case, the correct file was icudt62l.dat when using the runtime nodejs10.x for my lambdas. If you're not deploying node_modules as part of your lambda, you can grab the correct .dat file and deploy that.
I ran into the same error message when upgrading the runtime version of some old lambdas from nodejs6.10 to nodejs10.x. In my case, the file icudt58l.dat (compatible with nodejs6.10) was deployed into the project root, and the value of NODE_ICU_DATA was . (i.e. the directory where my lambda executes, equivalent to /var/task/).
To get a compatible .dat file, I re-installed the full-icu package using the node version used by the lambdas:
npx -p node#10.x npm i full-icu
It's important that the version of the .dat file is correct for the runtime version your lambdas are using. Initially, I made the mistake of just running npm i full-icu using node version 10.0 but this installed the wrong version of the .dat file and I just got the same error message again.
Finally, I copied the file node_modules/full-icu/icudt62l.dat into the project root and deleted the old icudt58l.dat so that it ends up in /var/task/ where the lambda can find it when NODE_ICU_DATA=..
Related
I've recently migrated my project to Angular 13. It builds locally on my Mac, however it's started to fail when I run it in my Docker build container (tested both locally and on our CI/CD server.
It's complaining about the DeckGL import:
Cannot find module '#deck.gl/layers' or its corresponding type declarations.
1 import * as Layers from '#deck.gl/layers';
Cannot find module '#deck.gl/geo-layers' or its corresponding type declarations.
2 import * as GeoLayers from '#deck.gl/geo-layers';
Cannot find module '#deck.gl/aggregation-layers' or its corresponding type declarations.
3 import * as AggregationLayers from '#deck.gl/aggregation-layers';
I've used npm list to ensure the dependencies are the same on my Mac and within the Alpine container and have also tested using the same Node version (and have tried a couple of different Node / Apline images), however, the issue persists, whilst still working locally.
Any ideas what could be causing this?
Really silly issue, but posting an answer in case someone runs into a similar issue in future.
I had accidentally run npm install in a top-level directory, and had installed some Node modules that didn't end up in my package.json file. In my case, I had the core deck.gl module installed in my package.json, but none of the layer packages (which are separate npm modules).
When I was running it locally, it was finding the correct dependency, but when running it on the CI/CD environment, it was obviously failing.
I am working on an application via the toolchain tool on IBM Cloud and editing the code via the Eclipse Orion IDE. As I am not accessing this through my local cli, my understanding is that in order to so call npm install {package}, I would just need to include the package in the package.json file under dependencies and require it in my app. However, when I load the application, I get the require is not defined indicating that the package has not been installed. Moreover, the require() is being used in the app.js file with the application being launched but not from files in my public directory.
After playing around further, it seems it might have to do with the way the directory tree is being traced as the error is only thrown in subdirectories. For example, require('express') works in app.js which is in the main directory ./ but fails when it is called in test.js in ./subdirectory/test.js. I feel like I'm missing something painfully simple like configuration of endpoint or something.
I've been searching around but I can't seem to find how to get the packages loaded, preferably without using the cli. Appreciate any pointers. Thanks!
Update: After playing around further, I am also getting module is not defined error when trying to require from another file in the same directory. For example module.exports = 'str' returns this error. While trying to require('./file') returns the require is not defined. It might have to do with how node is wrapping the functions?
Update 2: Tried "start": "npm install && node app.js" in package.json but no luck. Adding a build stage which calls npm install before deployment also does not work
Update 3: After adding npm install build stage, I am able to see that the dependencies have been successfully built via the logs. However, the require is not defined error still persists.
Update 4: Trying npm install from my CLI doesn't work as well even though all packages and dependencies are present
Update 5: Running cf restage or configuring cache via cacheDirectories does not work as well
Opened a related question regarding deployment here
Found out my confusion was caused due to me not realizing that require() cannot be used on the client side unless via tools such as Browserify.
I'm using an AWS Ubuntu 16.04 LTS following Hyperledger Fabric readthedocs tutorial. I followed steps in "Writing Your First Applications". When I ran "node enrollAdmin.js", a eCert and key material is expected to be generated in a hfc-key-store directory, but nothing is generated in this folder, which means the folder is still empty after running the command. I looked into the code in this js file, in lines 54-55, only two arguments are provided, but from the API from this link:https://jimthematrix.github.io/FabricCAClient.html#enroll__anchor, the fabric_ca_client.enroll function should receive three arguments, which means the third argument 'csr' is not given in the js file. Strangely, no error information is shown after running the command, and the only information i got from the terminal is "store path: $mypath/hfc-key-store".
Any one knows what the problem occurs?
Thanks
After I switch node version from 6.12.0 to 6.9.5, this issue is resolved. Looks like the node version has to be 6.9.x
I'm working on updating my project from using electron version 1.2.5
to the newest electron at this time which is 1.7.7 (atleast it was when I downloaded it). My node version 6.9.1.
I've encountered a problem when I start my project with this new electron version,
the error in general is about "could not locate the binding files. and it mostly regards the async module.
There is also some part of the exception regarding node-etcd module which I use in my project (version 5.0.3)
I found some information about this type of exception online but most of them says stuffs about rebuilding some node module using some npm commands which I didn't quiet understand. I tried to install async module again in a new folder and replace it (with its deps) in the node modules folder im currently using for my project, but I still got the same error.
I'm working in an offline enviorment where I can't take my project "out" to a computer with internet access, I can only bring things from the web to my project (like installing in some folder and then copying that into my project) so any npm or other commands that require web connection are not available to me directly on my work computer. (I can only use them in a different computer and copy the results to a flash drive and bring them to th
Here's 2 pictures of the error (sorry about the quality, its the best I could get):
First part of error
Second part of error
The solution that fixed the problem in my case was going into node_modules - > deasync - > index.js
Before line 31 I added a newline (next to the binding line)
and wrote:
modPath = __dirname;
This solution is hacky, it was accually ly found by an associate a while back, so I am not sure why it works, it might be an issue in deasync, but it fixed the problem.
Probably it is not specifically related to webpack/memory-fs, but I am getting the RangeError: Maximum call stack size exceeded error (see below for a call stack).
I have found out, that __dirname on Azure (webapp) returns \\100.78.172.13\volume-7-default\8f5ecde749dace2bb57a\4e07195f015b45ce8e9ba255dc901988\site\repository\Source\Website\Content\app\node_modules\webpack\node_modules\memory-fs\lib\normalize.js in my situation, while process.cwd() returns D:\home\site\repository\Source\Website\Content\app.
Is anything can be done from my side to configure node js to return D:\... instead of \\.. ?
Gist
How to reproduce:
Clone the https://github.com/intellismiths/webapp1 repository.
Create new Azure Web App (default settings).
Configure deployment source to use GitHub.
Click Sync. It will take 10+ minutes to complete and it will show that the deployment was successful.
Go to Application settings in Azure and change WEBSITE_NODE_DEFAULT_VERSION to 6.2.2
Go to kudu page and open powershell console.
Execute npm cache clean
Check node version by executing node -v. It should be v6.2.2
On Azure, navigate to D:\home\site\respository\src\WebApp1
Execute npm run build
In console, you should see a lot of errors which indicates that modules can not be resolved.
OPTIONAL. Test npm run build on your local machine - it should produce wwwroot/app.js without errors.
Update webpack.config.js to include context: __dirname to fix previous errors.
Execute npm run build
In console, you should see the "RangeError: Maximum call stack size exceeded" error.
Update 1
I only tried to set 6.2.2 runtime after adding the second package.json, so the project structure is not the simplest possible. Maybe just setting node to 6.2.2 breaks the build.
I could reproduce your issue following your steps. I found the key point was setting the WEBSITE_NODE_DEFAULT_VERSION to 6.2.2. And I found the webpack task worked fine if the WEBSITE_NODE_DEFAULT_VERSION was under 6.
Please downgrade the setting WEBSITE_NODE_DEFAULT_VERSION to the version under 6 e.g. 5.9.0 if your node.js modules do not need such high version.
And according the package.json of angular2 athttps://github.com/angular/angular/blob/master/package.json, it seems that the angular2 repository requires the node.js version between 5.4 and 6.
Additionally, the web application's root directory on Azure Web Apps is D:\home\site\wwwroot. So if you want to build your frontend project on Azure Web Apps, you need to locate to D:\home\site\wwwroot\wwwroot\mobile-web-app then run npm run build.
It's been fixed in master and it's proposed to be included in v6.4.0.
See: https://github.com/nodejs/node/issues/7175#issuecomment-239824532 and https://github.com/nodejs/node/pull/8070
After a long day of research, trial-and-error and various experimentation, I've found an acceptable workaround if you're not willing to downgrade to Node 5.*:
Downgrade to Node 6.1.0
Make sure to install webpack globally (with npm install -g webpack).
Just using 6.1.0 gets around the "maximum call stack size exceeded" error, but instead gave me a lot of resolve failures when running webpack from node_modules (using ./node_modules/.bin/webpack). Installing webpack globally finally got me past that.
If I understand it correctly, this whole issue with __dirname in Node >= 6.2 resolving to the UNC folder path instead of the mounted path is going to be fixed, there's an active discussion here.
I had the same issue.
Fixed it with UPGRADING npm not DOWNGRADING.
Bug is fixed in the npm versions newer than 6.5.
https://github.com/aumanjoa/chronas-community/blob/master/package.json#L48
I believe that your __dirname shows your persistant drive where the data is stored, while .cwd gives current directory from where node ran. This is because Azure runs from the Drive but files are stored at the persistent drive.
In your Gruntfile.js add
module.exports = function (grunt) {
grunt.file.setBase(__dirname);
// Code omitted
}
Refer: link