Good time of day!
The projects collect Gulp, I came to the conclusion that in order to support these projects, it is necessary to know the version of the collected pages hosted on a remote server and the version of the source that would know that a server is always available a new version of the assembly. Do to this problem some sort of plug-Gulp, which, when you build the project, such as a key --production stamped version of the bottom of the page, or in a special unit in the comments?
A popular plugin that can do this is gulp-bump, and there's the newcomer gulp-append.
But also check out the answers at gulp: Automatically add version number to request for preventing browser cache
Related
Is it possible to run a js file locally that downloads a secondary file and then run the latter?
I know the best thing would be to download the file from the server and save it locally, I would just like to understand if there is still the possibility to do the above.
Example:
Open terminal
1- node index js
2 - download scripts js in the same directory as index.js
3 - download is complete, start script js automatically.
Even if it is possible to solve it with Node.js workarounds (like requireing your puppeteer script from an url etc.) I strongly suggest to use Git with your team to share the latest version of your script. Version control is a must in modern software development, especially if you are working in a team. By learning the 6-7 most basic git commands you can solve almost everything you need for the current use case.
There are many good tutorials how to get started with git, I recommend GitHub's https://try.github.io.
Of course: you need to convince your team to embrace the change, or in better case they are already using it for version control, so it will be familiar to them.
You will need to:
Install Git locally;
Create a new repository on a server where you can store the latest stable versions of all your scripts (if it is not an open source project make sure it is private! GitLab, GitHub and Bitbucket provides/hosts free private repositories that will suit your needs);
Share the HTTPS (or SSH) URL of the repository with your team (e.g.: https://github.com/.../puppeteer-scripts.git) which they can clone;
Make sure your changes are pushed to the remote git repository;
Your team can pull the latest changes to their local computer (it will be their responsiblity to check if there were changes in the scripts, but you can notify them as well - there are automatic notifications if one starts to "watch" a git repository);
Lastly
Git can be frightening at first sight, but it can be learned in a few days and it makes code sharing smooth within your team.
One of Git's tagline describes very well why it will solve your problem:
--everything-is-local
I have a .NET solution - let´s call it bookshop, that contains multiple project: bookshop.web, bookshop.lib.
The bookshop.web is a web-application that display the content to the user. Bookshop.lib is a library that contains plenty of javascript code. The javascript code will be concated (with Gulp) to a single file with a release version number.
When I work with the solution I often change in both web and lib, and find parts of javascript code in the concatenated lib file that should not be in that particular version. We use Git and branches in our project, but the branch involves changes in both web and lib, so it is hard to separate it to only the javascript version.
Is there a way to have my solution in a Git repository, but have a branch that only affects the lib folder - and a branch that only can change the web? I want to be able to switch lib branches depending on it´s release version, without having to change the web branch.
Any advice on this working progress problem would be great.
Like explained in this topic, there's a feature in git called submodule to handle nested git repositories. I think it's the way you should take.
Another useful link ! Good read :)
I recently started using js libs and have a question regarding them.
It's possible to include their source, but then there is a problem with versions, as there are two options: add version to file name, but then all includes will have version appended to file name, which will cause trouble when you will update version. If version isn't specified in file name it's not clear what version is, but it's not that big problem, as you can go inside js source and see it's version.
Another option is to link to libraries hosting url, but it'll add additional overhead to download them and when external host will be unreachable, your site won't be able to load that library.
There seem to be maven plugins for some js libraries, but they are usually 3rd party and frequently they refer to outdated versions.
The ideal solution will be something maven-like but with official support.
Also as a comment advises it's possible to use some sort of bundling, but bundling happens after building, so it's still a question how to keep those js libs before bungling.
Please advise.
For many projects it is not necessary to stay at the bleeding edge of 3rd party libraries. Like for jQuery, a new version can maybe break some of the plugins you use. So you have to check and test everything first before deploying a new version.
Having the version in the filename is considered good practice though, because it prevents caching issues and allows you to cache files for a very long time (since the browser will always download a file when the filename has changed).
Regarding the issue you pointed out with the libraries hosting url, they are true so far. But you also need to consider, that when those are widely used (which they are) the library may already be cached in your browser and therefore the browser won't need to download it again. You can check out https://developers.google.com/speed/libraries/devguide for a library hosting by Google, which you can expect to be pretty reliable I guess.
All that being said, it depends on the project. If you need 100% reliability you need to host the library by yourself. If you're fine with Google's reliability, go for library hosting.
As your edit pointed out bundling: https://github.com/bower/bower check this out. It is a package manager for installing dependencies etc. on frontend projects. Should be exactly what you're looking for.
My web application uses a bunch of javascript files and I want to version them as and when different releases of my app are out. This is so that the users do not have to clean the cache everytime I publish a new js with my release.
Example for version 0.0.5 for my app I want all my js to be inside app/js/0.0.5/common/ etc
I am using maven. But have no clue how to automate this kind of versioning. I know one thing for sure, will need a replace plugin to replace all tokens in my jsps to the right version number at build time.
You can force browser not to cache files that may update in future like this:
<script src="/app/js/0.0.5/common?nc=<generate unique string here>"></script>
so src will be different every time so browser will not cache this script
I am about to release a javascript library.
I would like to save the file as [library-name].1.0.0
Then as the library will evolve you will be able to download new versions, e.g.
[library-name].1.0.1.js
[library-name].1.0.2.js
[library-name].1.0.3.js
[library-name].1.1.0.js
[library-name].1.2.0.js
[library-name].2.0.0.js
My question is: is there any reason not to save the version in the name of the file?
I am using other 3rd party libraries and the ones for which I don't store the version I always have to figure out if I have to upgrade or not.
For instance, I use codemirror.js, and I always wonder if I am using the latest version.
If you are giving it for download, then its a good idea to have version number as part of file name. Also its a good idea to add version number along with the license info at the beginning of the file like jQuery does
Checkout - http://code.jquery.com/jquery-1.9.1.min.js
Only case where you shouldn't add version number is when you are referencing a script file throughout your website - because you don't want to change all references whenever you update the script.
I've never released any libraries myself, but putting the version number in the file name sounds like a fine idea to me.
On upgrading, I think not putting the version number in the file name is used for libraries where the author doesn't expect to introduce breaking changes in future versions, only bug fixes and additions that don't affect code already written against the library. This means that people who use the library but don't host it themselves (i.e. who point to the library on a public CDN) automatically point to the latest version, and thus get bug fixes without having to do anything.
But, as you say, for people who download the library and host it themselves, it does mean they have to open the library file to check the version number.
If you want to match what some other library publishers do, you might want to have a look at Semantic Versioning - it codifies the x.x.x version numbering system.
And if you're going to release your library through Github (which I believe is what the cool kids do these days), you might want to use Jonathan "Wolf" Rentzsch's system for doing semantic versioning there.
If you are using unit tests you can make sure that the V1 unit tests all work fine against V2 before releasing the library.
Smashing article on js unit testing
If I understood your question correctly, one reason not to include the version name is that if you're hosting the script users using that CDN-hosted file don't have to change any code when you upgrade.