To reduce bloat and make it possible to dynamically opt for eventually used packages, I wrote a specific of that is capable to read out package configuration during the startup of an application, making it easy to hook into the startup process of an app and decide what kind of packages have to be registered with the software, and - additionally - load package information from external files, providing runtime contexts to make sure various environments and their respective configurations can be considered. However, combining the Package Loader with NPM and some customizing leverages ExtJS application building. Not only has the app.json to know what packages might(!) be used with your software - which contradicts the use case of over-the-air drop-ins of additional functionality-you also have to adjust your build process with specific flags so that the packages get properly build: sencha app build production -uses The Sencha Package Loader allows for dynamic package loading (hence the name), although these packages have to be linked against the application: exposing information about the requirements of an application comes with the expense of more configuration. The Sencha PackageLoader makes it all more bearable, but if you’re looking for a solution for dynamic package management with Sencha ExtJS, you have to add a few workarounds and be patient when wrapping your head around error messages that basically give no hint about what really went wrong when sencha app build fails with cryptic console output.Ī brief introduction to Sencha Ext JS and NPM can be found here:
However, Sencha is still locked deep in the basement together with Java and Ant, and getting things to work with Sencha CMD (on which ExtJS obviously still depends on) rather than Babel (for transpiling) and NPM can be quiet troublesome. JavaScript development got a lot more easy with NPM. Sencha CMD packages were never flexible enough for providing real dependency management with Sencha projects. Sencha ExtJS Packages have always been a tool for organizing your code into smaller, more deliverable, reusable chunks and might have been a good way to maintain company code for various projects, but it was never flexible enough for providing dependency management of 3rd party code we have been looking for many, many years, and where Sencha obviously missed to jump the bandwagon once the time was right. 2 and Sencha CMD 3.1- which was never really successful when you look at it from the external- dependency-managagement-and-centralized-repository-for-3rd-party-code-point of view ( phew!). If you remember the early days of Sencha ExtJS, you might think of the “package manager” that was introduced with ExtJS 4. Resolving application dependencies became more convenient with the introduction of package managers, such as Composer (PHP) and NPM (mainly JavaScript).
0 kommentar(er)
