This is how my bower.json file looks like:
{
"name": "myproject",
"version": "0.0.1",
"private": true,
"author": "Tom",
"dependencies": {
"requirejs": "~2.1.10",
"requirejs-domready": "~2.0.1",
"ac-core": "git+http://ac-src/ac/bower-ac-core.git#^0.14.1",
"ac-grid": "git+http://ac-src/ac/bower-ac-grid.git#^0.13.1",
"ac-sparkline": "git+http://ac-src/ac/bower-ac-sparkline.git#^0.6.1",
"ac-highcharts": "git+http://ac-src/ac/bower-ac-highcharts.git#^0.3.2",
"ac-ilist": "git+http://ac-src/ac/bower-ac-ilist.git#^0.4.1",
"ac-tree": "git+http://ac-src/ac/bower-ac-tree.git#^0.1.1",
"ac-legacy": "git+http://ac-src/ac/bower-ac-legacy.git",
"lodash": "~2.4.1",
"angular-toastr": "0.4.0"
},
"devDependencies": {}
}
This file was created 1 year ago. After that several changes were made to all the modules we are using and major versions of all the modules are changed now.
Because of Semantic Versioning, I am not allowed to update packages to their latest available version.
How can I force bower to update all the packages to its respective latest available version?
How can I also update bower.json file so that the next person trying to update the bower packages does not face the same issue.
Removing SemVer helped. This is how the bower.json file looks now:
{
"name": "myproject",
"version": "0.0.1",
"private": true,
"author": "Tom",
"dependencies": {
"requirejs": "~2.1.10",
"requirejs-domready": "~2.0.1",
"ac-core": "git+http://ac-src/ac/bower-ac-core.git",
"ac-grid": "git+http://ac-src/ac/bower-ac-grid.git",
"ac-sparkline": "git+http://ac-src/ac/bower-ac-sparkline.git",
"ac-highcharts": "git+http://ac-src/ac/bower-ac-highcharts.git",
"ac-ilist": "git+http://ac-src/ac/bower-ac-ilist.git",
"ac-tree": "git+http://ac-src/ac/bower-ac-tree.git",
"ac-legacy": "git+http://ac-src/ac/bower-ac-legacy.git",
"lodash": "~2.4.1",
"angular-toastr": "0.4.0"
},
"devDependencies": {}
}
Related
What is the 'dev' dependency version?
E.g. here:
{
"name": "ntbjpb--run",
"version": "0.0.0",
"private": true,
"dependencies": {
...
"#progress/kendo-angular-progressbar": "^0.2.3",
"#progress/kendo-angular-toolbar": "dev",
...
},
"scripts": {
"ng": "ng",
"start": "ng serve",
...
},
"devDependencies": {
"#angular-devkit/build-angular": "~0.901.1",
"#angular/cli": "~9.1.1",
...
}
}
"#progress/kendo-angular-toolbar": "dev"
I tried to google it, but all my research comes to the devDependencies which is not what I am looking for I guess.
The best match I got was this question. But the answer to it states:
So using dev as a version number is not allowed.
While we can clearly see from the stackblitz example I linked above that it is not the case and the dev is allowed to be used in the place of the version number.
That string mean install the module tag <dev> as reported in docs npm install [<#scope>/]<name>#<tag>
In fact, looking the versions of that module you will see the tag defined:
There is a similar post here:
My custom NPM Package is not found,
but that did not resolve my issue.
Could not find a declaration file for module '#dc_microurb/common'.
'/Users//Projects/ticketing/auth/node_modules/#dc_microurb/common/build/index.js'
implicitly has an 'any' type. Try npm install #types/dc_microurb__common if it exists or add a new declaration
(.d.ts) file containing `declare module '#dc_microurb/common';
There is no #types/dc_microurb__common and I am unclear as to why it is suggesting to create a new .d.ts file, when that happens automatically during the build process.
This is the package.json file inside my published package:
{
"name": "#dc_microurb/common",
"version": "1.0.5",
"description": "",
"main": "./build/index.js",
"types": "./build/index.d.ts",
"files": [
"./build/**/*"
],
"scripts": {
"clean": "del ./build",
"build": "npm run clean && tsc",
"pub": "git add . && git commit -m \"Updates\" && npm version patch && npm run build && npm publish"
},
"keywords": [],
"author": "",
"license": "ISC",
"devDependencies": {
"del-cli": "^3.0.1",
"typescript": "^4.0.5"
},
"dependencies": {
"#types/cookie-session": "^2.0.41",
"#types/express": "^4.17.9",
"#types/jsonwebtoken": "^8.5.0",
"cookie-session": "^1.4.0",
"express": "^4.17.1",
"express-validator": "^6.6.1",
"jsonwebtoken": "^8.5.1"
}
}
Anybody with experience in publishing packages on npm where TypeScript is involved? I am unclear as to why this package is not being found by my auth service when it is successfully installed inside that service.
Did I mess up in the way I am exporting inside my common/src/index.ts file?
export * from './errors/bad-request-error';
export * from './errors/custom-errors';
export * from './errors/database-connection-error';
export * from './errors/not-authorized-error';
export * from './errors/not-found-error';
export * from './errors/request-validation-error';
export * from './middlewares/current-user';
export * from './middlewares/error-handler';
export * from './middlewares/require-auth';
export * from './middlewares/validate-request';
Does it all have to be inside a module.exports instead?
So after reviewing a few blogs on Medium on how this is done, I noticed a couple of things.
Inside my tsconfig.js, this was missing:
/* Advanced Options /
"forceConsistentCasingInFileNames": true / Disallow inconsistencies */
So I manually added it in, secondly, I noticed something I meant to remove earlier but forgot. So instead of this:
{
"name": "#dc_microurb/common",
"version": "1.0.5",
"description": "",
"main": "./build/index.js",
"types": "./build/index.d.ts",
"files": [
"./build/**/*"
],
I needed to have it like this:
{
"name": "#dc_microurb/common",
"version": "1.0.6",
"description": "",
"main": "./build/index.js",
"types": "./build/index.d.ts",
"files": [
"build/**/*"
],
After making those couple of corrections, now my package is available to my auth service.
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'm making a web server with Node.JS and use Travis-Ci to check my code. Yhe problem I got is when I commit my code, Travis gives error below, but the code compiles without an error on my pc:
./backend/server.js: 1: Syntax error: ( unexpected
Here you could find my .travis.yml file:
install:
- npm install
- npm install -g bower
- bower install bootstrap
- bower install socket.io
language: node_js
node_js:
- "6.9"
before_script:
- chmod 0777 ./backend/server.js
cache:
directories:
- node_modules
- bower_components
and the package.json
{
"name": "watchfriends",
"version": "0.0.0",
"description": "Front-end and back-end project watchfriends",
"main": "gulpfile.js",
"scripts": {
"test": "./backend/server.js"
},
"repository": {
"type": "git",
"url": "git+https://github.com/WatchFriends/Backend.git"
},
"author": "Hein P., Jasper D., Michiel V., Michiel Z.",
"license": "ISC",
"bugs": {
"url": "https://github.com/WatchFriends/Backend/issues"
},
"homepage": "https://github.com/WatchFriends/Backend#readme",
"devDependencies": {
"gulp": "^3.9.1",
"gulp-autoprefixer": "^3.1.1",
"gulp-clean-css": "^2.0.13",
"gulp-concat": "^2.6.1",
"gulp-csslint": "^1.0.0",
"gulp-htmlhint": "^0.3.1",
"gulp-jshint": "^2.0.4",
"gulp-notify": "^2.2.0",
"gulp-sass": "^2.3.2",
"gulp-sourcemaps": "^2.2.0",
"gulp-uglify": "^2.0.0",
"jshint-stylish": "^2.2.1"
},
"dependencies": {
"socket.io": "^1.5.1"
}
}
On this gist, you could find my code, including the log.
Did I something wrong?
Thanks in advance.
Travis runs npm test when testing your code.
If you check inside of your "package.json" file then you can see that the test script is set to run ./backend/server.js. You need to run the node file with node.
Change that to node ./backend/server.js and hopefully that'll work.
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.