Skip to content

Conversation

@RaenonX
Copy link

@RaenonX RaenonX commented Sep 11, 2025

Thanks for the project!

This includes the following changes:

  • Some project files update, including /dist removal, Makefile args updates
  • GLPK version bumped to v5
  • Split exports / typings for Web Worker / Node version
    • Since Web Worker mostly returns Promise<> due to the nature of web workers while Node returns synchronously, I split the typing to GLPKWebWorker and GLPKNode.
    • This should help addressing Types do not include Promise<> #43.
  • Added terminate() for both version to help memory management. This should help addressing Managing memory for multiple LP instances #45
  • Added Github Actions workflow for automated version publishing

Since I am having a rather faster pace on my main project depending on this. I have included these commits, made them to be v5, and published on https://www.npmjs.com/package/@raenonx/glpk.js.

Signed-off-by: RaenonX <[email protected]>
Signed-off-by: RaenonX <[email protected]>
Signed-off-by: RaenonX <[email protected]>
This splits the import namespaces to ensure the typing is correct.

`terminate()` is also added for GC. Without `terminate()`, WASM could easily get OOM since the webworker instance is not terminated.

Signed-off-by: RaenonX <[email protected]>
Signed-off-by: RaenonX <[email protected]>
In v5.0.0, `import glpk from '@raenonx/glpk.js'` was not possible. It had to be either `@raenonx/glpk.js/web` or `@raenonx/glpk.js/node`. After this commit, `import glpk from '@raenonx/glpk.js'` is now possible (again) with the constructed instance always being async.

Signed-off-by: RaenonX <[email protected]>
@jvail
Copy link
Owner

jvail commented Sep 20, 2025

Salut @RaenonX, thank you for sharing. I am a bit less fast paced it seems ... good that you have solved your problem with your own package: Keep the PR open please I will need a bit of time to look into it and it is certainly a good idea to renovate the whole lib.
However, I am surprised that you have not switched to another LP solution in wasm. I am sure there are new/better ways to do that nowadays since the C lib of GLPK hasn't been updated since 2000. Out of curiosity: Why are you still using this library?

@RaenonX
Copy link
Author

RaenonX commented Sep 20, 2025

Salut @RaenonX, thank you for sharing. I am a bit less fast paced it seems ... good that you have solved your problem with your own package: Keep the PR open please I will need a bit of time to look into it and it is certainly a good idea to renovate the whole lib.
However, I am surprised that you have not switched to another LP solution in wasm. I am sure there are new/better ways to do that nowadays since the C lib of GLPK hasn't been updated since 2000. Out of curiosity: Why are you still using this library?

No problem, I can keep the PR open!

tbh I forgot the exact reason why I picked this package over other packages initially, but I didn't switch because I find it too much to switch given that I broke the implementation regarding GLPK in my code to many pieces.
My gut feeling was (fixing this package + experience building and publishing package) is better than (trying other packages + loss of the experience building packages + the risk of the same OOM issue) so I ended up stayed using this package

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants