With the always growing number of javascript libraries and frameworks used in web interfaces, it becomes soon a requisite to keep track of the scripts used, of their version number, and of their dependencies in the ecosystem of internal tools and external websites developped, whether for enterprise or personal projects.
The approach I advice for that is two-fold: a synthetic document and an active watch process.
The synthetic document should contain the following informations:
And that for each project/tool/website, hence displayed in a tabular way, with for each of them a graphic icon stating the status of the used version (up-to-date or not), as well as its version number.
Ideally, the synthetic document should also tell where the libraries/frameworks are called in the code for each project and/or enable a direct link towards the concerned files in the version manager system (SVN, Git…).
The active watch process consists in checking regularly the latest version that can be used in production (it is useless to follow the Release Candidates), and this is where the RSS feeds and other automation tools are useful. Some projects are updated more often than others, like jQuery which delivers a minor release about every month.
Cascading dependencies between libraries and frameworks are a phenomenon to keep in mind, as the version upgrades are also done in a cascade way.
For instance, if you follow the couple jQuery/jQueryUI, the latest version of the second may not support the latest of the first for a few weeks. There is no need to be up-to-date with only one link in the chain, this is the whole dependencies chain that has to be up-to-date.
The problem is even more complex when you develop your own scripts on top of a framework. Will they be compatible with its latest version?
In general, both frameworks and libraries follow the principle of backward compatibility: the code written for their previous versions are still working with the latest (the previous example with jQuery/jQueryUI is therefore hypothetical), even if they can lose some performance between versions. It is thus important to note under which version of its underlying framework a script has been developped to know when you should revise your code.
To be sure of this compatibility, the best way is to use an automatised interface test tool (see Selenium for example).
The approach I advice for that is two-fold: a synthetic document and an active watch process.
The synthetic document should contain the following informations:
- list of the used libraries and frameworks
- last version number and its publication date
- dependencies with other third-party scripts (with their version number)
- URL of the website where to download the latest version
- where to find data about the latest version (download page, change log, blog, RSS feed…)
And that for each project/tool/website, hence displayed in a tabular way, with for each of them a graphic icon stating the status of the used version (up-to-date or not), as well as its version number.
Ideally, the synthetic document should also tell where the libraries/frameworks are called in the code for each project and/or enable a direct link towards the concerned files in the version manager system (SVN, Git…).
The active watch process consists in checking regularly the latest version that can be used in production (it is useless to follow the Release Candidates), and this is where the RSS feeds and other automation tools are useful. Some projects are updated more often than others, like jQuery which delivers a minor release about every month.
Cascading dependencies between libraries and frameworks are a phenomenon to keep in mind, as the version upgrades are also done in a cascade way.
For instance, if you follow the couple jQuery/jQueryUI, the latest version of the second may not support the latest of the first for a few weeks. There is no need to be up-to-date with only one link in the chain, this is the whole dependencies chain that has to be up-to-date.
The problem is even more complex when you develop your own scripts on top of a framework. Will they be compatible with its latest version?
In general, both frameworks and libraries follow the principle of backward compatibility: the code written for their previous versions are still working with the latest (the previous example with jQuery/jQueryUI is therefore hypothetical), even if they can lose some performance between versions. It is thus important to note under which version of its underlying framework a script has been developped to know when you should revise your code.
To be sure of this compatibility, the best way is to use an automatised interface test tool (see Selenium for example).
Suivi des bibliothèques Javascript (in French)
El seguimiento de las bibliotecas javascript (in Spanish)
O seguimento das bibliotecas javascript (in Portuguese)
No comments:
Post a Comment