Closed Olivier-Boudeville closed 10 months ago
You're right, the part about having eqwalizer_support ebin
dir populated with BEAM files is a leftover from the rebar section.
To clarify several points here:
apps
part of the build_info.json
, and type-checks them. BEAM files are used for dependencies: eqWAlizer loads type and line/col information from them, but does not type-check them. Hence the absence of type-errors here.apps
part of the JSON file, including eqwalizer_support
.eqwalizer_support
has, for some reason, been renamed into just eqwalizer
for mini-elp's tests. I agree it's confusing. eqwalizer_support
can be obtained here, and is needed as it contains the definition of some types used internally by eqWAlizer.I'll clarify/add this info to the docs. Thanks for the feedback!
Thanks for your answer! Even if due to parse-transforms I am more fond of tools operating on BEAM files, I will surely give Eqwalizer a try in the future. I close this issue, thanks again for your feedback!
Hi,
Thanks for this interesting tool!
When reading https://github.com/WhatsApp/eqwalizer#using-it-with-non-rebar-projects (with Erlang 26.1) I have been a bit confused by:
At least if no relevant eqwalizer dependency is listed in the conf file, no error is found afterwards, whereas a ebin full of BEAM files with certainly many type errors was specified:
(if it is due to no proper eqwalizer or eqwalizer_support being specified in the conf file, then maybe a check could be made and an error be raised?)
For more information, here is the very basic conf/xxx-for-eqwalizer.json file (a version of it without eqwalizer-related app/dep; slightly edited):
On a side note, maybe I missed it in the doc, but it would be interesting to state whether eqwalizer relies on the BEAMs and/or on the source files to operate; I expected the BEAMs (which is fine, notably if user code uses very custom-built, possibly with parse transforms), as the app's
ebin
directory has to be specified, but on the other handsrc_dirs
may/must be specified as well.