Migrating the web part of the project to TypeScript?

[kichMan]

What do you think about migrating the web part of the project to TypeScript? I am currently refactoring your project, including using TypeScript, as it helps me better understand the code. If you are interested, we could continue this work. In the future, to prevent users from having to convert the project from TS to JS, this operation could be automated using GitHub Actions.

[qu1ck]

I have considered it and its a good idea in general but I could not think of a way to do this gradually because the logic is currently split among files and has some cross dependencies that would make it tricky to satisfy the TS checker unless everything is moved to TS at once. And I couldn't justify the time it would take to migrate everything.

But my frontend experience is very limited so I'm open to suggestions here.

Some additional points to keep in mind with such migration:

• Compatibility with custom scripts (user.js) should be maintained, i.e. functions and global variables should not be renamed by TS compiler/packer/any other tools that may be involved
• Transpiled files should not be checked in, if a file is migrated it should be replaced by a .ts variant and it should be added to automatic build action that will integrate it into end user installable pcm package (zip archive).

[kichMan]

@qu1ck Would you mind if I add you to my repository where I am migrating to TypeScript? There, you will be able to leave your comments and respond to my questions regarding the migration.

[qu1ck]

What do you mean by add? Is it not on github? You can just @ me in your fork issues/comments and I'll get a notification.
Happy to answer questions.

[kichMan]

@qu1ck

Compatibility with custom scripts (user.js) should be maintained, i.e. functions and global variables should not be renamed by TS compiler/packer/any other tools that may be involved

Which specific functions and global variables were you referring to?

[qu1ck]

Basically everything in global namespace.
Custom scripts were given very wide capabilities to override anything and hook into any logic, look at examples https://github.com/openscopeproject/InteractiveHtmlBom/wiki/Customization#examples

It would be ok to wrap everything into a module so that scripts have to change XXX to ibom.XXX for example. But it would not be ok to have a minimizer mangle all names into an unpredictable mess because that will make that kind of customization effectively impossible to maintain with ibom updates.

[kichMan]

i.e. you meant the EventHandler object and its event names defined by the IBOM_EVENT_TYPES constant, right?

export const IBOM_EVENT_TYPES = {
    ALL: "all",
    HIGHLIGHT_EVENT: "highlightEvent",
    CHECKBOX_CHANGE_EVENT: "checkboxChangeEvent",
    BOM_BODY_CHANGE_EVENT: "bomBodyChangeEvent",
} as const;

const EventHandler = { /*...*/ };

[qu1ck]

No, I mean everything in global namespace, every function that is not defined inside another function and every global variable.
Customization is not limited to that basic event system.

In short, don't use code minimizer or obfuscator and if possible dont use modules and it should be fine.

[kichMan]

Oh, this is very bad. This condition makes refactoring for scalability impossible.

What do you think about prohibiting the use of global variables and functions in the next major version, or would it be better to release the changes as a separate project?

I assume that in this case, adapters and event subscribers will be needed. However, to add them, me need to understand what goals they are required for by the users.

[qu1ck]

It doesn't make refactoring impossible. There is no requirement to treat all function and variable names as immutable API that is set in stone. You can change them when needed.

You just can't make the whole concept of adding custom javascript useless because all of ibom code is now a minimized mangled unreadable mess that changes non deterministically every minor release, which would be the result of typical webpack output with optimizations turned on.

What do you think about prohibiting the use of global variables and functions in the next major version, or would it be better to release the changes as a separate project?

It is an option but the benefits would have to outweigh the loss of flexibility in custom code. Right now I don't foresee any code scalability issues that would require this change.