You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For portability across different execution environments, we would like to adopt require-by-string in Fusion. This is mostly doable and would be a huge boon to the project.
The only issue at the moment is that our use of an init file for the Fusion module is currently being impeded by the Rojo project refusing to adopt the portable require-by-string standard.
Figure out some way to hack portable require-by-string
Ideally, we would not break our user's workflows, but unless we find a good solution to this, it may be impossible to avoid while also expanding our compatibility guarantees. We need to make this choice sooner or later because otherwise we will be incompatible with the rest of the modern ecosystem, and we do not want to be taken hostage by our technology choices.
The text was updated successfully, but these errors were encountered:
So objection to bullet # 2:
Dropping Rojo support altogether would be a huge loss because I (and several studios I've done work for) use it for version control of components... A lot of them work towards fully-managed Rojo and Fusion was a way to get UI in Git...
I think it should be possible to maintain support for now. I really don't want to drop support either because I think that would also be counterproductive.
For portability across different execution environments, we would like to adopt require-by-string in Fusion. This is mostly doable and would be a huge boon to the project.
The only issue at the moment is that our use of an
init
file for the Fusion module is currently being impeded by the Rojo project refusing to adopt the portable require-by-string standard.We are faced with a few options:
Ideally, we would not break our user's workflows, but unless we find a good solution to this, it may be impossible to avoid while also expanding our compatibility guarantees. We need to make this choice sooner or later because otherwise we will be incompatible with the rest of the modern ecosystem, and we do not want to be taken hostage by our technology choices.
The text was updated successfully, but these errors were encountered: