New project structure / beginning of plugins #184
Merged
Conversation
This file contains 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
Making plugins necessitated a new project structure, as we're going to need to publish a separate library for plugin authors so they can use them. We'll also need a bunch of the modules they'll use, so we need the least stressful way of depending on the libraries we publish. Creating a separate repo would make our lives very difficult, so I added a projects directory at the top level, and the published libraries go in there. We utilize path dependencies for our internal libraries. I also added the beginnings of a plugin architecture, but I wanted to get this change out before it gets too big. Plugins are quite complicated, and we're going to need to do a bit of refactoring when we add one. That refactoring, plus all of this moving would make the PR very difficult to review. This PR also includes a new genserver dispatcher so that the compile tracer isn't slowed down by extraneous work.
scottming
reviewed
May 26, 2023
|
In addition to the mentioned issues, we also need to consider the problem of Diagnostics clearing, which doesn't seem to be reflected in this PR. For example, the diagnostic clearing of Mix shouldn't clear Credo's Diagnostics. |
scottming
reviewed
May 26, 2023
|
This pr doesn’t build diagnostics yet, that’s going to be another large change |
scottming
reviewed
May 26, 2023
scottming
reviewed
May 26, 2023
scottming
reviewed
May 26, 2023
apps/remote_control/lib/lexical/remote_control/compilation/dispatch.ex
Outdated
Show resolved
Hide resolved
scottming
reviewed
May 26, 2023
apps/remote_control/lib/lexical/remote_control/compilation/dispatch.ex
Outdated
Show resolved
Hide resolved
The name lexical conflicted with the language server's app and formatting would fail because it was using lexical's mix project. This was also reflected by the necessity of creating a unique name for the project, the fix was just masking the problem.
If we can't find the formatter, we were running the formatter with default options, which would be annoying if you've configured the formatter, and you'd just get the defaults. This could be annoying. This change makes a best effort to find the .formatter.exs in the parent directories of your application, and it stops at the app root. If it's not found in any of the parents, you get default options.
I kept having to update the apps at the top of this file whenever I added, removed or renamed a dependency. This is annoying, and I thought it would be a lot easier to just let the mix.exs control which apps are needed by remote_control.
This is a good point, let me share my strategy with you now. I want to normalize all diagnostic messages to utilize the plugin replies --even builds. Each plugin will then own a specific source (and we'll treat ours with the source of
|
|
Apply your last suggestions: #184 (comment) Then you are good.😊 |
scottming
approved these changes
May 29, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Making plugins necessitated a new project structure, as we're going to need to publish a separate library for plugin authors so they can use them. We'll also need a bunch of the modules they'll use, so we need the least stressful way of depending on the libraries we publish.
Creating a separate repo would make our lives very difficult, so I added a projects directory at the top level, and the published libraries go in there. We utilize path dependencies for our internal libraries.
I also added the beginnings of a plugin architecture, but I wanted to get this change out before it gets too big. Plugins are quite complicated, and we're going to need to do a bit of refactoring when we add one. That refactoring, plus all of this moving would make the PR very difficult to review.
This PR also includes a new genserver dispatcher so that the compile tracer isn't slowed down by extraneous work.