Hi @sematik, thanks for your answer.
What I really want in the future is to be able to:
- Add new custom features to the suite if I need it, it is much more comfortable to work with the content of the source folder.
- Build my own version of the library by modifying or adding new modules.
- To compile the library using @babel/plugin-transform-runtime and remove some helpers that are repeated in multiple modules such as __extends, __assign, etc.
- Keep a useful repository in Github updated. This is not actively maintained.
I have spent the last weeks studying the code and have accumulated a little experience on how things are handled. I’ve also been watching how some bugs are fixed, it’s interesting. Also, the original directory structure can be found in some modules that include this information.
Since the code is released under the GPL license this would allow users to modify it and distribute these modifications under the GPL license, so it is possible to rebuild the directory structure or create your own and reverse the transpilation of some modules back to Typescript, but as I said, this can be a bit laborious. There are currently about 200 modules within suite.js. The code in suite.js is not entirely obfuscated, so there may not be an advantage in not distributing the source folder as in previous versions. This is a regression with respect to the previous version.
What does “the complex structure of these components” really mean? If you tell me: “we have the policy of not supplying the source folder for the GPL version” I would understand.
The question arises with the comment of @Stanislav :
“the full sources code contains a separate css file per widget”
But where can I find a css file for each widget? Thanks in advance
PD: I think I’ve been too insistent with this, excuse me if that’s the case