Replies: 3 comments 4 replies
-
|
Just a note here to remember: switching here a default branch from main branch to develop (same as what was done in v3) is a little bit breaking. In v3 it doesn't matter that much cause it's alpha-stage, but here there are 262 forks already. Most of the forks are "main" clone only probably (cause it is a default way to fork). So everyone will need to update their fork to take "develop" branch as well. I'm telling this, because I had this issue with v3 change, I've seen updates in the main repository, used Github functionality to update my fork, but couldn't find the reason why I can't update them, to find out some time later the default branch has switched :) Such change here would require some form of announcement at least. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with you 100%, but I have an idea to rename the |
Beta Was this translation helpful? Give feedback.
-
|
There was a time I was drawing some form of diagrames to find out where is what and why, but it's WIP, and I'm not sure if it could be helpful there. But will be happy to share if needed
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks @paireks, good for a start! Could you please send a screenshot in a higher resolution? If it's possible. |
Beta Was this translation helpful? Give feedback.
-
|
@DhivinX Here it is, just load it in https://app.diagrams.net/. I did it for myself initially, but maybe with your input we could make it a part of documentation in the future, so please edit it according to your needs :) |
Beta Was this translation helpful? Give feedback.
-
See below..
Main reason would be that currently we bundle everything, viewer and plugins, into the same binaries, which includes a bunch of 3rd-party libraries that support various plugins. For example, we have various loader plugins, like This means that these 3rd-party libraries are bundled with the binary regardless of whether users use them, and that user's apps have to have those 3rd-party libs as npm dependencies, even if not using them. But then, some users just import the source files straight out of The 3rd-party dependencies are only these: ` which is not a lot..
Just briefly for this discussion: I was thinking that there would be a package for each plugin in
Now I'm starting to wonder if it's overkill to make this a monorepo, since |
Beta Was this translation helpful? Give feedback.
-
|
Yes it's true, xeokit/sdk is a perfect example for using monorepo. I have the same doubts as you, and sooner or later you will switch to v3, while v2 will become the LTS version. What I'm most afraid of when modifying version v2 is the possible lack of backward compatibility with already working applications, as these changes may be breaking. In any case, the decision is yours, think it over carefully, in the meantime I can start working on examples of using xeokit-bim-viewer, see #1417 |
Beta Was this translation helpful? Give feedback.
-
Hello,
I have been observing and analyzing this repository since the beginning of the week and wondering what would be the best way to convert it into a monorepo. I need help understanding:
Are any external repositories required for this to work?
I wonder if it is possible to convert them into a monorepo in a reasonable time, many changes could be breaking, are there specific reasons for this?
I'm trying to understand what could be included in
packages, I would need a description or diagram of what would be included there.I can't think of anything else at the moment. First of all, I need alignment from you @xeolabs
Beta Was this translation helpful? Give feedback.
All reactions