I am trying to setup my environment to do some client side development. It is supposed to be nodejs based. I was recommended grunt-express as the component to configure the development server.
The problem I have is that the latest version (0.3.6) does not work and I am not sure is this because I am doing something stupid with the configuration or this is a bug introduced in the latest version.
Here is what I have:
The Gruntfile.js
'use strict';
module.exports = function(grunt) {
var path = require('path');
grunt.initConfig({
express: {
server: {
options: {
port: 3005,
bases: path.resolve('public'),
debug: true
}
}
}
});
grunt.loadNpmTasks('grunt-express');
grunt.registerTask('start', ['express', 'express-keepalive']);
}
The package.json:
{
"name": "MvcTemplate",
"version": "0.0.1",
"engines": {
"node": ">0.8"
},
"private": true,
"dependencies": {
"grunt": "~0.4",
"grunt-express": "~0.2"
}
}
when I run grunt start the version of the package as specified above works fine - the server is started and responds to the requests as expected.
But if I switch to the latest version (0.3.6) when I run the grunt start or grunt express all I am getting is a constant stream of the messages CreateProcessW: The system cannot find the file specified.
So - is it me being stupid or something is wrong with the package?
Just tried it on my machine (OS X, Node: 0.10.9) and version 0.3.6 seems to work fine.
Try changing ports, or clearing npm cache, or removing node_modules?
Related
In the documentation for visionmedia's debug module for Node.js, I see that it is possible to enable and disable different debug targets programmatically.
My attempts to do this have not been very successful.
I created a barebones script: test.js
const debug = require("debug");
let test = debug("test"); // created before being enabled
console.log(1, debug.enabled("test"));
let namespaces = debug.enable("test");
// test = debug("test");
console.log(2, debug.enabled("test"));
console.log("enabled namespaces:", namespaces);
test("this is test");
namespaces = debug.disable();
// test = debug("test");
console.log(3, debug.enabled("test"));
console.log("disabled namespaces:", namespaces);
test("you shouldn't see this");
When I run the script using node test.js, I get the following output, which shows that debug.enable("test") has neither enabled the test debug target, nor has it returned any namespaces:
1 false
2 true
enabled namespaces: undefined
3 false
disabled namespaces: undefined
When I run the script using DEBUG=test node test.js, I get the following output, which shows that debug.disable("test") has neither disabled the test debug target, nor has it returned the names of any disabled namespaces:
1 true
2 true
enabled namespaces: undefined
test this is test +0ms
3 false
disabled namespaces: undefined
test you shouldn't see this +0ms
However, if I uncomment the lines that recreate the test debug target after using .enable() or .disable(), then everything works.
It seems that, in order to be able to enable and disable debug targets programatically, I need to use a different syntax:
debug("test")("message which can be enabled or disabled");
But it seems that this creates a new debug instance each time it is used, which would be wasteful. And it is not the standard syntax described in the documentation. And, even so, the .enabled() and .disabled() methods do not return a list of namespaces.
Is there something that I have badly misunderstood?
The issue was caused because I was relying a version of debug installed as a dependency for express. It turns out that the current version of express requires an outdated version of debug.
After running npm install express today (27 June 2021), the entry for debug in package-lock.json was as follows.
"debug": {
"version": "2.6.9",
"resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz",
"integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==",
"requires": {
"ms": "2.0.0"
}
"version": "2.6.9"
(This is version "4.17.1" of express.)
This is because the package.json file for express explicitly calls for "debug": "2.6.9".
Running npm update has no effect on this.
Running npm install debug does fix the problem. The entry for debug in package-lock.json gets set to the following:
"debug": {
"version": "4.3.1",
"resolved": "https://registry.npmjs.org/debug/-/debug-4.3.1.tgz",
"integrity": "sha512-doEwdvm4PCeK4K3RQN2ZC2BYUBaxwLARCqZmMjtF8a51J2Rb0xpVloFRnCODwqjpwnAoao4pelN8l3RJdv3gRQ==",
"requires": {
"ms": "2.1.2"
}
"version": "4.3.1"
Problem solved.
Note: this is a Q&A on migrating AWS Lambda Webpack builds from v6.10 to v8.10 — no help is needed, but even better answers are of course always encouraged!
For a while now I have been a disciple of using Webpack to build my back-end Lambdas after reading James Long's excellent series entitled "Backend Apps with Webpack" (part 1, part2, and part3).
Up until recently, the only version of Node.js that Amazon Web Services offered was 6.10; you had to write your Lambda fn in the "callback" style. But on April 2, 2018 AWS announced that 8.10 was now supported, and with it the suggested pattern is async / await which is great! Until it immediately broke my Webpack build. After a bit of debugging, I can break my build just by adding one async fn to the Lambda handler (I don't even need to call it):
async function firstAsync() {
return true;
}
exports.handler = async (event) => {
// TODO implement
return 'Hello from Lambda!'
};
To be clear, doing this in the AWS Lambda console is perfectly fine, runs great. Webpack even builds it successfully, but upon uploading to AWS Lambda, I get the following error message: regeneratorRuntime is not defined. My code is below. What am I needing to do?
webpack.config.js
const nodeExternals = require('webpack-node-externals');
const path = require('path');
const UglifyJsPlugin = require('uglifyjs-webpack-plugin')
const webpack = require('webpack');
const config = {
entry: './src/index.js',
output: {
path: path.resolve(__dirname, 'dist'),
library: 'index',
libraryTarget: 'commonjs2',
filename: 'index.js'
},
target: 'node', // building for a Node environment
externals: [nodeExternals()], // in order to ignore all modules in node_modules folder
module: {
rules: [{
test: /\.(js|jsx)$/,
use: {
loader: 'babel-loader',
options: {
presets: ['env']
}
}
}]
},
plugins: [
new UglifyJsPlugin()
]
};
module.exports = config;
package.json
{
"name": "lambda-webpack",
"version": "1.0.0",
"description": "An empty project scaffold to enable webpack builds in AWS Lambda",
"main": "index.js",
"scripts": {
"build": "webpack",
"upload": "upload.bat"
},
"author": "Geek Stocks®",
"license": "MIT",
"devDependencies": {
"aws-sdk": "^2.179.0",
"babel-core": "^6.26.0",
"babel-loader": "^7.1.2",
"babel-preset-env": "^1.6.1",
"uglifyjs-webpack-plugin": "^1.1.6",
"webpack": "^3.10.0",
"webpack-node-externals": "^1.6.0"
}
}
Geek Stock's answer above is only necessary when using the Node v6.10 runtime. It allows you to use async/await syntax and babel-runtime/regenerator converts your async functions to ES6 generators which is supported on Node v4.3.2 and newer runtimes.
In Node v8.10 though, it is different. async/await is already supported so you don't need Babel to convert your async functions to generators. You just use it correctly and it works.
As for your specific situation, I assume you simply changed your Javascript code to use async/await code but you didn't tell Babel NOT to convert your async/await code to generators. That is why babel-runtime is complaining about a missing plugin.
If this is the case, you simply need to configure Babel to simply target Node v8.10. You can do it like this in your .babelrc...
{
"presets": [
[
"env",
{
"targets": {
"node": "8.10"
}
}
]
]
}
babel will then stop converting those async functions. And since it's not doing a conversion, it will not need the regenerator-runtime anymore.
In my case I'm using it with nodejs12.x. I'm receiving the error regeneratorRuntime is not defined.
I was using preset es2015 and stage-0 with a node12.x code. Also I'm using an older version of babel.
What I did, installed:
"#babel/cli": "^7.10.1",
"#babel/core": "^7.10.2",
"#babel/preset-env": "^7.10.2"
And then set this babel preset:
"presets": [
["#babel/preset-env", {"targets": { "node": "current" }}]
]
Thanks,
To begin using async / await in your Webpack-built code, you need a little help from Babel, specfically the babel-runtime and the babel-plugin-transform-runtime. Fortunately there is a really good writeup on the installation and use of both here on the Babel website. You need Babel to do the following for you:
Automatically requires babel-runtime/regenerator when you use
generators/async functions.
I won't repeat what has been written there, however, of particular note is HOW you need to install these, because while their writeup certainly works for most, there is a needed tweak for some AWS Lambda devs who have not needed runtime dependencies before now.
The first part is pretty normal, you need new devDependencies:
npm install --save-dev babel-plugin-transform-runtime
And also you need to tweak your .babelrc file like they describe:
{
"plugins": [
["transform-runtime", {
"helpers": false,
"polyfill": false,
"regenerator": true,
"moduleName": "babel-runtime"
}]
]
}
But here is the kicker, and this is new to the code above: the babel-runtime is a regular dependencies, not a devDependencies:
npm install --save babel-runtime
These 2 installs and the .babelrc tweaks do SOLVE the async / await problem described above, but it introduces a new problem to the build above: Cannot find module 'babel-runtime/regenerator'.
If you are at all concerned with keeping your Webpack built code small, you are likely also using webpack-node-externals like the above code does. For example, the aws-sdk for JavaScript in Node is very large and is already available in the Lambda environment, so its superfluous to bundle it again. The webpack-node-externals configuration above configures Webpack to ignore ALL the modules in node-modules by default, and there is the root of the new problem. The newly installed babel-runtime is a module that needs to be bundled in the build in order for Lambda to run correctly.
Understanding the problem then, the answer becomes simple: don't use the default configuration. Instead of passing in nothing to webpack-node-externals, configure it like this:
externals: [nodeExternals({
whitelist: [
'babel-runtime/regenerator',
'regenerator-runtime'
]
})], // ignore all modules in node_modules folder EXCEPT the whitelist
And that solves both the original async / await problem, and the (possible) new problem you may be encountering if you had no previous dependencies in your build. Hope that helps — happy Lambda awaiting!
I am going through the 5 minute quickstart of Angular 2. However, my application resides in src/ folder instead of at the root of my repository, and when I run npm start the application is trying to find an index.html file at the root. I read up on lite-server and documentation shows that it uses BrowserSync and I can reconfigure BrowserSync with a bs-config.json in my repository. I did that and this is what my config looks like:
{
"port": 8123,
"server": { "baseDir": "./src" }
}
According to the log it's using the specified config:
[1] > todo-app-angular2#1.0.0 lite E:\GitHub\todo-app-angular2
[1] > lite-server "./bs-config.json"
I also tried an override through bs-config.js
module.exports = {
port: 8123,
server: {
baseDir: "./src"
}
};
However the Angular application is still opened on port 3000 and it's disregarding the baseDir defined in the config. What am I doing wrong?
You should use a file called bs-config.js (instead of a bs-config.json one) since lite-server tries to load a module using the require function. The configuration should be a valid Node module:
module.exports = {
"port": 8123,
"server": { "baseDir": "./src" }
};
See this line in the source code: https://github.com/johnpapa/lite-server/blob/master/lib/lite-server.js#L20.
This file by default is loaded from the user's project folder.
Edit
After digging a bit more, the first part of my answer relies on the code from github but not the one actually installed using npm install (version 1.3.4)
There are two options in this case:
port
baseDir
Using this command will fix your problem:
$ lite-server --baseDir ./src --port 3333
Hope it helps you,
Thierry
The answer from Thierry Templier is not quite correct (anymore), you can use either the bs-config.json or bs-config.js configuration to adjust your browser-sync configuration. This is what I came up initially for the angular2 quick start example with JIT(Just-In-Time) and AOT(Ahead-Of-Time) compilation support (bs-config.json)
{
"port": 8000,
"server": ["app", "."]
}
to host the project from multiple directories.
However, I did not like this solution because by overwriting the server section in the json file, the default middleware configuration was overwritten at the same time.
Therefore I ended with the following approach, I took the default lite-server's config-defaults.js files and modified it instead (bs-config.js):
'use strict';
var fallback = require('connect-history-api-fallback');
var log = require('connect-logger');
/*
| For up-to-date information about the options:
| http://www.browsersync.io/docs/options/
*/
module.exports = {
port: 8000,
injectChanges: false, // workaround for Angular 2 styleUrls loading
filters: ['./**/*.{html,htm,css,js}'],
watchOptions: {
ignored: 'node_modules'
},
server: ['./', 'app'],
middleware: [
log({ format: '%date %status %method %url' }),
fallback({
index: '/index.html',
htmlAcceptHeaders: ['text/html', 'application/xhtml+xml'] // systemjs workaround
})
]
};
Interesting problem, Using harp to build a simple app, then deploying it to Heroku, which is proving to be an issue. The last deploy worked flawlessly using the Harp buildpack, But now it's breaking on deploy.
Nothing has changed that should be causing this, no updates to node modules, or node version. the logs and Papertrail are complaining:
Error: `libsass` bindings not found. Try reinstalling `node-sass`?
After this, I branched off and tried to check on lib-sass in
/app/node_modules/harp/node_modules/terraform/node_modules/node-sass/lib/index.js:22
As per the logs, tried reinstalling it, but no avail. Anyone ever run into this? could it be a problem with the buildpack?
seems to be an issue with Node 0.12.
https://github.com/zeke/harp-buildpack/issues/12
I was able to get my app running by just not using the buildpack, adding
"dependencies": {
"harp": "~0.12.1"
},
"scripts": {
"start": "node server.js"
},
"engines": {
"node": "0.10.x"
},
to package.json and adding a server.js with
require('harp').server(__dirname, { port: process.env.PORT || 9000 })
Im trying to upload a node.js app into cloud foundry, im not going to use Express Framework, but when doing "vcm push" Im getting this error.
Uploading Application:
No such file or directory - /Users/jtomasrl/Code/node/pronto/node_modules/express
here is my package.json
{
"name": "karaoke-api",
"version": "0.0.1",
"dependencies": {
"pronto": "*",
"pronto-mongodb": "*"
},
"engines": {
"node": "0.8.x",
"npm": "1.1.x"
}
}
Just for the sake of providing an "answer", when this situation does arise, it's worth emptying node_modules/.bin or even removing node_modules itself and re-installing modules with;
npm install