fix(engine): preload deps and don't prune code paths#768
Merged
Conversation
I found a doozy of a bug when compiling a work project. For reasons, one of our erlang libraries is a fork of a well-known http client, but its application name isn't the same as the library's app name. Another dep does checks for the client module being present, and if it's present, then reads the app config's vsn with the library's name. The problem is there is no app config, since the app name doesn't match the library name. This causes the build to fail, but only in expert. The reason is that expert has previously loaded the app name when compiling other deps, and because module pruning was disabled, that old dep carried through and caused the compile issue. This does not happen on the command line, because when the project stack changes, the dep's modules are unloaded. Expert originally disabled module pruning because it needs to have its own deps' modules available, but this can be accomplished by passing an argument to the project-level builds instead of always doing it when we need to be in a mix context.
scohen
changed the title
|
Successfully created backport PR for |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I found a doozy of a bug when compiling a work project. For reasons, one of our erlang libraries is a fork of a well-known http client, but its application name isn't the same as the library's app name.
Another dep does checks for the client module being present, and if it's present, then reads the app config's vsn with the library's name. The problem is there is no app config, since the app name doesn't match the library name. This causes the build to fail, but only in expert.
The reason is that expert has previously loaded the app name when compiling other deps, and because module pruning was disabled, that old dep carried through and caused the compile issue. This does not happen on the command line, because when the project stack changes, the dep's modules are unloaded.
Expert originally disabled module pruning because it needs to have its own deps' modules available, but this can be accomplished by passing an argument to the project-level builds instead of always doing it when we need to be in a mix context.