-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option to statically check modules as they’re loaded #121
Comments
Referenced by RFE3818 (MarkLogic-intneral) |
Interesting, I think I'd make use of this right away. The bulk of the work will be in ml-javaclient-util, which provides support for module loading, but both ml-app-deployer and ml-gradle will need little tweaks. So something like this? gradle -PstaticCheck=true mlWatch |
@jmakeig To confirm - I think we'd need to use xdmp:invoke, as xdmp:eval will be a pain with trying to escape single or double quotes. So the module would be loaded first, and then we'd do a static check via xdmp:invoke - which is consistent with what you mention about leaving the target modules database in a bad state, which is fine - that's already happening today. The goal is getting feedback about it right away. |
Did a first cut, this should be easy to add - marklogic/ml-javaclient-util@f6fd3ec |
What about a pre-commit trigger with a global Boolean to toggle? |
As a developer, I’d like to know if my code doesn’t work before I load it into a modules database via ml-app-deployer. The best check is to run unit tests, but this would be boot and suspenders to have a static check for each module loaded. This is especially relevant at development time when the watcher is loading one module at a time. Obviously we probably wouldn't want this to be the default because it will likely slow down loading. (Will it? How much?)
xdmp:eval()
andxdmp:invoke()
include astatic-check
option to statically analyze a module without running it.My expectation would be that module loading ceases entirely with an exception at the first static error that it encountered with enough detail to pinpoint the module, line, and column of the failed code. (Yes, this potentially leaves the target modules database in a partial state.)
The text was updated successfully, but these errors were encountered: