I'm trying to run GAS in vs codium using node.js, npm and clasp.
Everything is synced correctly but the autocompletion is not working (it worked before but no more)
when I look in the directories, I see this in package.json:
"dependencies": {
"#types/google-apps-script": "^1.0.56"
}
and this in package-lock.json:
"dependencies": {
"#types/google-apps-script": "^1.0.56"
}
},
"node_modules/#types/google-apps-script": {
"version": "1.0.56",
"resolved": "https://registry.npmjs.org/#types/google-apps-script/-/google-apps-script-1.0.56.tgz",
"integrity": "sha512-3YGOtRlnWPSARl/n2BKt0qiIA6Y3/5BLC2zH9s/jcu+1rpxR07noLCFxTZ2BQBIfDl6+Vs9iKjLTgdbbL8q/mg=="
}
},
"dependencies": {
"#types/google-apps-script": {
"version": "1.0.56",
"resolved": "https://registry.npmjs.org/#types/google-apps-script/-/google-apps-script-1.0.56.tgz",
"integrity": "sha512-3YGOtRlnWPSARl/n2BKt0qiIA6Y3/5BLC2zH9s/jcu+1rpxR07noLCFxTZ2BQBIfDl6+Vs9iKjLTgdbbL8q/mg=="
}
}
I'm not familiar with node nor npm, is there a possible conflict ? I see two package.json files, one in the main directory and one in nodes_modules#types\google-apps-script, and package-lock.json is also in the main directory and in node_modules.
Related
Several months ago, I set up a production NodeJS app that uses mongoose to connect to a MongoDB database with the following connection string:
mongodb://#127.0.0.1:27017/invoice_app?retryWrites=true&w=majority
I did not need to supply a username or password and everything worked.
I wanted to make a copy of the NodeJS project on the same server and point it to the same database. I'll call this the staging NodeJS project. However, everytime I try to npm start my staging project, I get the error (node:11495) UnhandledPromiseRejectionWarning: MongoParseError: No username provided in authority section.
As far as I can tell, this staging project is the exact same as the production one. Line by line, they should be the same, except they are in different directories. I reused the exact same connection string. The NodeJS project is used owned/executed by the same user.
Why can mongoose connect from one directory but not another? Is there something else I completely misunderstood?
The issue was that I had deleted the node_modules directory from my staging project along the way. And when I ran the npm install in the staging directory, it didn't actually give me the correct node_modules package versions as production. Here was the relevant lines from package-lock.json that resolved my issues in staging:
"mongodb": {
"version": "3.3.5",
"resolved": "https://registry.npmjs.org/mongodb/-/mongodb-3.3.5.tgz",
"integrity": "sha1-ONUxATr+3pKw3SguO588CMm9/zs=",
"requires": {
"bson": "^1.1.1",
"require_optional": "^1.0.1",
"safe-buffer": "^5.1.2",
"saslprep": "^1.0.0"
}
},
"mongoose": {
"version": "5.7.13",
"resolved": "https://registry.npmjs.org/mongoose/-/mongoose-5.7.13.tgz",
"integrity": "sha1-2Ou8Fc+xnQFM8fvUt69BPXWVLUY=",
"requires": {
"bson": "~1.1.1",
"kareem": "2.3.1",
"mongodb": "3.3.5",
"mongoose-legacy-pluralize": "1.0.2",
"mpath": "0.6.0",
"mquery": "3.2.2",
"ms": "2.1.2",
"regexp-clone": "1.0.0",
"safe-buffer": "5.1.2",
"sift": "7.0.1",
"sliced": "1.0.1"
},
"dependencies": {
"ms": {
"version": "2.1.2",
"resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz",
"integrity": "sha1-0J0fNXtEP0kzgqjrPM0YOHKuYAk="
}
}
},
"mongoose-legacy-pluralize": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/mongoose-legacy-pluralize/-/mongoose-legacy-pluralize-1.0.2.tgz",
"integrity": "sha1-O6n5H6UHtRhtOZ+0CFS/8Y+1Y+Q="
},
I have a css build task that merges resources from bower dependencies and my own css.
The build task is part of project that uses git source control. The project has been running correctly for well over a year.
Up until yesterday, everything was working correctly on my windows laptop, when I reinstalled my npm dependencies that run the build task.
Below is a simplified example
gulpfile.js
var gulp = require('gulp'),
$ = require('gulp-load-plugins')();
gulp.task('default', function () {
return $.merge (
gulp.src('./bower.json')
.pipe($.mainBowerFiles('**/*.css', {
includeDev: 'exclusive',
group: 'css'
})
),
gulp.src(['./source/css/styles.css'])
)
.pipe($.plumber())
.pipe($.concat('stylesheet.css'))
.pipe(gulp.dest('./build/css'))
});
package.json
{
"name": "merge",
"version": "1.0.0",
"description": "",
"main": "gulpfile.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"devDependencies": {
"gulp": "^3.9.1",
"gulp-concat": "^2.6.1",
"gulp-load-plugins": "^1.5.0",
"gulp-main-bower-files": "^1.6.2",
"gulp-merge": "^0.1.1",
"gulp-plumber": "^1.1.0",
}
}
And bower.json
{
"name": "merge",
"description": "",
"main": "gulpfile.js",
"authors": [
""
],
"license": "ISC",
"homepage": "",
"private": true,
"ignore": [
"**/.*",
"node_modules",
"bower_components",
"test",
"tests"
],
"devDependencies": {
"normalize-css": "^7.0.0",
"reset-css": "^2.2.1"
},
"group": {
"css": [
"reset-css",
"normalize-css"
]
}
}
Prior to yesterday the task would merge both sources declared in $.merge(...). Since yesterdays' npm install I am finding that the merge will only output the result for the first declared source.
After some testing I have found that if I reverse the order of the merge sources than both sources are merged to the set output destination.
var gulp = require('gulp'),
$ = require('gulp-load-plugins')();
// the order of the sources has been reversed
gulp.task('default', function () {
return $.merge (
gulp.src(['./source/css/styles.css']),
gulp.src('./bower.json')
.pipe($.mainBowerFiles('**/*.css', {
includeDev: 'exclusive',
group: 'css'
})
)
)
.pipe($.plumber())
.pipe($.concat('stylesheet.css'))
.pipe(gulp.dest('./build/css'))
});
The problem with this solution is that that output content reversed, which may cause issues with style inheritance etc. This change to a successful output makes me think there may be an issue with how and where .pipe($.mainBowerFiles(...) is declared.
I've also tried replacing installed modules for gulp-merge and gulp-main-bower-files respectively with merge2 and main-bower-files.
Using either one or both solved the problem, however this isn't an ideal workaround as it means an update to the gulp task and installed modules.
This sudden failure to output tasks merge css ( or js ) in my project has real issues for any historic commit or branch in the project.
Is there away I can diagnose the failure of the original $.merge(...), or a way that I can retroactively replace gulp-merge with merge2 across all commits my git project and any branches?
I try to use Jest with bablejs and ES2017 in my project, according to the Jest Getting Started page and also Bablejs config for ES2017 this is my .babelrc file :
{
"presets": ["es2017"],
"env": {
"test": {
"presets": ["es2017"]
}
}
}
And my package.json is:
{
"name": "",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "jest"
},
"repository": {
"type": "git",
"url": ""
},
"author": "",
"license": "ISC",
"bugs": {
"url": ""
},
"homepage": "",
"devDependencies": {
"babel-cli": "^6.26.0",
"babel-core": "^6.26.0",
"babel-jest": "^21.2.0",
"babel-polyfill": "^6.26.0",
"babel-preset-es2017": "^6.24.1",
"jest": "^21.2.1"
}
}
When I type npm test to run all my test with jest i get these error :
){import StateList from './StateList';
^^^^^^
SyntaxError: Unexpected token import
It means it doesn't know import.
babel-preset-es2017 does not transform import statements, because it only includes the plugins: syntax-trailing-function-commas and
transform-async-to-generator.
When installing babel-preset-es2017 you also get a warning that it has been deprecated in favour of babel-preset-env, which contains everything that the es201x presets contained and more.
warning babel-preset-es2017#6.24.1: 🙌 Thanks for using Babel: we recommend using babel-preset-env now: please read babeljs.io/env to update!
As shown in the Migration guide from es2015 to env, it is a drop-in replacement.
npm install --save-dev babel-preset-env
And change your .babelrc to:
{
"presets": ["env"]
}
Do not confuse babel-preset-env with Babel's env option, which I have removed from your current config, since you are using the exact same presets for the test environment as for any other, so it doesn't have any effect.
You can configure babel-preset-env to only transform features that are not supported by the platform you target, for example { "targets": { "node": "current" } } will only transform features that aren't supported by the Node version you are running. If no targets are specified, it will transform everything. For details see the Env preset documentation.
Note: With the upcoming version 7 of Babel, the official packages will be published under the namespace #babel, which means that babel-preset-env will be #babel/preset-env.
Got very strange issues. Basically i decided create my own npm package, and publish it to the world. During development, I was testing it as s simple node module, and was able to use it using next code:
var r = require('./lib/%mymodulename%');
Of course it was in the lib folder.
Now, I organised it as a npm package, and my package.json looks next:
{
"name": "mymodulename",
"author": "xxx",
"description": "xxx",
"version": "0.0.1",
"homepage": "xxx",
"repository": {
"type": "git",
"url": "xxx"
},
"main": "/lib/mymodulename.js",
"scripts": {
"install":"node install.js"
},
"dependencies": {},
"engines": {
"node": ">=0.9"
}
}
when i am trying to test it via : npm install . -g it is installed successfully and i am able to see my local module via:
npm ls -g
however, when i am trying to use it in node file like:
var r = require('mymodulename') npm can't find it.
I think that i am missing something very small, but can't find what.
Thanks,
-D
Ok! Thanks for the answers.
It was totally my fault, and never put / for the main.
In my case i got :
"main": "/lib/mymodulename.js",
and it should be:
"main": "lib/mymodulename.js",
Thanks!
I've got a npm-shrinkwrap.json and a package.json in a git branch called "deployment".
On my servers, I fetch and merge this deployment branch from github. This ensures that my servers have the latest deployment version.
Because the node_modules binaries etc. are not being shipped, I need to run npm install or npm update on the server side too, after the project repository has been pulled from the server.
This is why I decided to use npm shrinkwrap. However, even when I have this npm-shrinkwrap.json in the main folder and run npm install, it still installs newer versions of submodules, even though the shrinkwrapped json file has locked these down. It seems like npm does not even look at the shrinkwrap file.
Could anyone explain why this happens, and how to resolve this situation?
This is part of package.json:
"dependencies" : {
"eventemitter2" : "0.4.9",
"after" : "0.4.1",
"express" : "2.5.9"
},
"devDependencies" : {
"mocha" : ">= 1.0.3 < 2",
"should" : ">= 0.6.3 < 1",
"request" : ">= 2.9.202 < 3",
"commander" : ">= 0.6.0 < 1"
},
Whereas npm-shrinkwrap.json is:
{
"name": "appname",
"version": "0.0.1",
"dependencies": {
"eventemitter2": {
"version": "0.4.9"
},
"after": {
"version": "0.4.1"
},
"express": {
"version": "2.5.9",
"dependencies": {
"connect": {
"version": "1.8.7",
"dependencies": {
"formidable": {
"version": "1.0.9"
}
}
},
"mime": {
"version": "1.2.4"
},
"qs": {
"version": "0.4.2"
},
"mkdirp": {
"version": "0.3.0"
}
}
},
"commander": {
"version": "0.6.0"
},
"should": {
"version": "0.6.3"
},
"request": {
"version": "2.9.202"
}
}
}
Yet, when I ran npm install it updated qs from version 0.4.2 to version 0.5.0. Also, it updated mime to 1.2.5. Why did it do this?
The npm install returned this:
qs#0.5.0 ./node_modules/express/node_modules/connect/node_modules/qs
mime#1.2.5 ./node_modules/express/node_modules/connect/node_modules/mime
Interestingly enough the shrinkwrap contains neither of these. I guess this is the problem. Now the question is why it did not contain these.
Your npm-shrinkwrap.json doesn't include connect's version of qs. You should npm install before you generate your shrinkwrap.