I user grunt-bumper to bump up my version in the package.json file if I release my app. I have a readme.md file included as well in which the current version is also described. I am no searching for a way that grunt updates this version tag automatically each time, I release my app.
I neither have found a plugin for this nor did I find an easy way to get this to work manually..
Does anybody have a clue how this can be done easily`and nice?
Related
I am pretty new to js. And I am looking to learn js. Recently I came across one library called bounce.js which is animation library. Which require NPM to install but why? I am dont want to use NPM (or any packet Manager) they havent provided min.js file to direct import in scrpit tag?? Why??. Similarly for Tailwind it require NPM. And as NPM require it means I need vercel to deploy and all stuff.
2) As I use django I dont know how to install NPM modules in my templates.
Please help me clear out from this mess.
When all I can find is NPM based installation guides I like to search the library name followed by CDN which typically brings up some minified results. In your case I tried searching for bounce.js CDN which brought up lots of results including this one:
https://cdnjs.com/libraries/bounce.js/0.8.2
which points to
https://cdnjs.cloudflare.com/ajax/libs/bounce.js/0.8.2/bounce.min.js
You should be able to do some searching and find the CDN you wish to use. If you want the source JS to serve from your own server you can visit the .js link and right click and download (or copy and paste into your own file).
One of the advantages of using npm over a direct download is facilitating the integration into your workflow.
For instance, if you use a module bundler, the bundler will generate an "optimised", minified version for you: Getting rid of unused code for you (=> Tree shaking) reducing the size of your resulting code, solving some import issues, and more
NPM will also help you keep track of your imported library. You know if you use an up-to-date or outdated version. It will also inform you about
Eventual securities issues. And much more.
There are many, many advantages of using npm over direct download.
I know the main advantages of package-lock.json and I agree with that. It not only locks the downloaded version in the last install, but also the uri... and that's required on most cases for being possible to replicate the most similar project as possible.
But one thing that seems weird to me is that package.json has the feature of declaring a dependency like dependency: ^1.0.0, that should make npm to download the most recent and compatible version of that package in each installation.
I'm working at a project that I actually need this. Otherwise every time my dependency releases a patch, it will be required to make a new commit updating package.json only changing the version, so my pipeline can also overwrite package-lock.json.
In short, it seems that while package.json uses a feature... package-lock.json prevents that one.
Am I missing something?
The point of package-lock.json is to accurately represent the tree as it actually exists at a point in time, so that someone cloning the project gets exactly the same tree you had.
If you want to upgrade that dependency to a newer version, just use npm update and then commit the updated package-lock.json. Other members of your team will get that update as part of the normal process of picking up the latest.
More in the npmjs.com page on package locks.
Let's consider as scenario where you and I are on a team and our project uses nifty-lib, with package.json saying "nifty-lib": "^0.4.0", and we don't share package-lock.json. Perhaps I've been working on the project a couple of months longer than you have and I got nifty-lib v0.4.0 when I installed it. But when you picked it up and installed, you got v0.4.1 (a bugfix update which, sadly, introduced a new bug). At some point, you notice what seems like a bug in our project, but I can't replicate it. We spin in place for a while trying to figure out why it happens to you and not to me. In the end, we realize it's because it's actually a bug in nifty-lib that they introduced in v0.4.1. Hopefully we then get 0.4.2 or something (or if there isn't one, we fix the bug and do a PR, meanwhile rolling back to 0.4.0 across the project).
If we'd been sharing package-lock.json, we wouldn't have spun in place wondering why the problem happened to you and not to me, because you would have had the same version of nifty-lib as me. As part of our normal cycle, we'd do npm update periodically, and if a new bug showed up in our tests, we'd know from the commit history that it was because of a bug in a dependency.
Now, for "me" and "you" read "dev" and "production". :-)
Which is why package-lock.json locks the version, but package.json lets you say "this or better". package-lock.json keeps your team unified on versions, but you can intentionally update with npm update, which shows up in the commit history so you can track down regressions to it.
As I mentioned in a comment above, the short answer is it makes updateing your dependencies easier.
However, another way I like to think about the two files is: package.json is the file the human reads, while package-lock.json is the file the computer reads.
NPM is a package / dependency manager. So, in your package.json file, you write out "these libraries are needed for my library to work." As a feature, you have a range of versions you can list a dependency at. This helps when you run npm update on a specific package. It'll look to see what is the latest version that matches within your *package.json**, and updates you lockfile.
The package-lock.json lockfile is useful because it verbosely describes what your node_modules/ folder looks like so it can be accurately recreated when someone else installs your library. Additionally, since this file is generated automatically, you don't have to worry about maintaining it.
Of course, all of this just happens to be how NPM (and conversely how most package managers) handle this. That is, there isn't a technical reason why we couldn't have one file to describe both the version range that would be allowed when running updates, and a verbose lockfile portion that pins versions to allow for a recreatable dependency tree.
Basically, it is just a convenience. You have one file to succinctly list what dependencies your projects needs. It is readable and easily updatable. The other file, the lockfile, is automatically generated and ensures each npm install gives you the exact same node_modules/ folder as before.
I was trying to run the demo for bootstrap-timepicker, the demoe references
jquery.min.js but from the JQuery download I got jquery-1.12.4.min.js .
What is the process in this case, is it to be understood to download the latest version and rename it to jquery.min.js or to change the reference from jquery.min.js to jquery-1.12.4.min.js.
I know using Bower would automagically get everything is needed but 1.My companies proxy settings was causing bower to time out and 2.Just want to know why a demo that is most likely is used by many correctly is pointing to a file that is not downloadable manually from JQuery site
You can do whatever you want in your own server. Keeping the version number will allow you to download multiple versions, in case your applications have version dependencies. If you rename it to jquery.min.js then you need to be very careful about upgrading it, because it could potentially break some applications if there's an incompatible change in the new version.
The demo probably doesn't use a version number because they didn't want readers to think it was dependent on a specific version.
I recently updated node.js and installed the latest version of cordova at the same time. In doing so I have some issues that I did not have before.
It says phonegap.js is depreciated and I need to replace it with cordova.js or plugins may not load
whitelist plugin warnings have started showing up:"No Content-Security-Policy meta tag found. Please add one when using the Cordova-plugin-whitelist plugin."
My plugins aren't loading on start up, but do on resuming.
The plugins is the only real issue, but I just wanted to list everything encase it gave a clue as to a solution. I have been trying for over a week to fix the plugins issue with no success. I can't just revert to the previous version as I don't know what it was.
Any ideas on possible solutions or suggestions as to what version I was likely to be using in order to have these issues now?
#Marty,
this is a common problem. You need to set your compiler to build version 3.7.0 or earlier. If you do not set the version when you build, you will get the latest version, and you get the issues you see. You can set this version on the command line when building an App from scratch.
You need to do the same with your plugins. You need to set the version with them also.
Since you are doing all this work, you may want to start adding the white-list plugin. It will be required after 4.0.0 to use the web.
In addition, you will want to start a move to NPM as the source of your plugins.
This FAQ will help
Top Mistakes by Developers new to Cordova/Phonegap
Read
#6 - Not setting the "phonegap version" for your compiler
#7 - Not setting "version" for you plugins
#10 - Not adding the new "white-list" and "white-list plugin" parameters in config.xml.
#11 - You need to get your plugins from NPM now.
I was just playing about with Bower and got it to pull down jQuery 1.9.1 and Fancybox 2.1.4
That's great but for example, Fancybox pulls it's entire repo down including all the demo files and not just the actual files I need.
How should this situation be dealt with?
Neil
You have three options at the moment:
Bug the author about either properly using the ignore attribute of the component.json (or soon to be bower.json) or maintaining a separate repository just for bower like AngularJS does for example.
Register and maintain a component yourself.
Pull in just the file you need via HTTP like this:
"dependencies": {
"fancybox": "https://raw.github.com/fancyapps/fancyBox/master/source/jquery.fancybox.js"
}
Last last option comes with the drawbacks that neither dependency resolution nor multiple files will work. The best long-term solution is to lobby the author to correctly support bower.