List view
Currently fusion.ssg client projects are quite heavy and upgrading them to work with newer versions of fusion.ssg is quite challenging. Suppose though if client projects were just composed of the src/ folder and some configuration files for whatever makes each project unique. That would nearly eliminate the need for having to upgrade a project to work with the latest version of fusion.ssg (though not entirely such as would be the case the specifications for the src folder change). It would also make the job of creating new client projects much easier and could possibly eliminate entirely the need to even have a dedicated app to generate a proper client project (such as the dependency on fusion.fpg).
No due dateRefactor for testing the viability of embedding fusion.ssg in projects. The advantage here is that projects are isolated from issues that could arise when a globally installed version of fusion.ssg (the server) is upgraded which could cause client projects to break. This does not, however provide a solution for upgrading a project to align with an upgraded fusion.ssg.
No due dateThis milestone is strictly dedicated to refactoring the typescript implementation in this project as well as upgrading to the latest version of TypeScript (and Eslint) and refactoring the code to take advantage of it. Much of the typescript that currently exists wouldn't be considered good TypeScript and it is quite verbose too. In addition, may objects should have been broken down into more qualified versions of those objects so as to reduce the amount of code blocking that is currently in place. A prominent example of this is the Asset type which should be broken down to the numerous types of assets that fusion recognizes. This alone would dramatically reduce the amount of code blocking that is currently in place when working with assets.
Overdue by 6 month(s)•Due by January 31, 2025•4/4 issues closed