You might ask why this is 'declarative' and that would be a good question. Here is why I consider this declarative:
Your dependencies are declared in the markup by special data attributes added to script and link[rel=stylesheet] tags. The dependencies get parsed and the markup can be automatically updated to the best available set of packages that satisfy these dependencies. What is neat is that the system will resolve dependencies as deep as needed and will insert the relevant script and link tags in the correct order.
Why is this different?
Most package managers focus on the offline development world. This scheme was designed specifically for Plunker [1] which is an online front-end development tool. This means that there are several constraints as well as several opportunities to change the front-end package management workflow.
I wanted users to be able to add packages to their existing html markup, however strangely they might have designed it. I also wanted the markup to look 'ok' after these new packages are inserted. This was quite a challenge. I also didn't want to include all of the packages' code in each Plunk as that would really slow down the service and increase storage costs.
As a result, a trade-off (and possibly benefit) I've achieved in this system is that all package ressources must be accessible online (ideally via CDN).
The result is a system whereby the markup declares package dependencies and can be introspected and updated to newer package versions and/or to identify existing packages.
Your dependencies are declared in the markup by special data attributes added to script and link[rel=stylesheet] tags. The dependencies get parsed and the markup can be automatically updated to the best available set of packages that satisfy these dependencies. What is neat is that the system will resolve dependencies as deep as needed and will insert the relevant script and link tags in the correct order.
Why is this different?
Most package managers focus on the offline development world. This scheme was designed specifically for Plunker [1] which is an online front-end development tool. This means that there are several constraints as well as several opportunities to change the front-end package management workflow.
I wanted users to be able to add packages to their existing html markup, however strangely they might have designed it. I also wanted the markup to look 'ok' after these new packages are inserted. This was quite a challenge. I also didn't want to include all of the packages' code in each Plunk as that would really slow down the service and increase storage costs.
As a result, a trade-off (and possibly benefit) I've achieved in this system is that all package ressources must be accessible online (ideally via CDN).
The result is a system whereby the markup declares package dependencies and can be introspected and updated to newer package versions and/or to identify existing packages.