Disabling warnings for unclassified modules

[jfpedroza]

Hi.

We are looking into introducing Boundary into our project, but the task of solving all the warnings would be too long and daunting. We managed to set everything up for a small app in the umbrella, but the main app is rather big and organized in a way that there is a lot of mixing of what should be several distinct boundaries. As Boundary works right now, it would probably require adding tons of boundaries with many dependencies and disabling checks a lot, which defeats the purpose. It is too strict. A gradual approach would be preferred.

We would prefer to start from the bottom up, refactoring smaller sections of the code and using Boundary for any new features, and work our way up until the top module can be a boundary. For that, I think the best way would be to have the option not to warn on un classified modules so we can include Boundary in parts of the app.

What do you think? Is that something that could be included?

Thanks.

[sasa1977]

Hi,

Making this check optional shouldn't be too difficult. But before I agree with such change, I'd like to discuss why current mechanisms aren't sufficient. Because obviously these various opt-outs will make it easier to circumvent boundary.

So when it comes to unclassified modules, getting rid of these warnings usually doesn't require a lot of work, because even in larger projects, there are typically only a few top-level "namespaces". So you only have to add use Boundary, check: [out: false] into those few modules, and you have no warnings 😄

Now, to have boundary check some small part of the code, you could turn it into a top-level boundary. E.g. something like:

defmodule Foo.Bar.Baz do
  use Boundary, top_level?: true
end

So Foo.Bar.Baz is now not a part of Foo, and it should be checked, and now you can try to make that part clean. As you're doing this with other parts, perhaps at some point you'll reach the stage where you can make Foo.Bar a top-level boundary (removing Foo.Bar.Baz & co in the process, or making them sub-boundaries).

Would that work for your case, or is it not enough?

Perhaps it would be beneficial if you could explain your situation and the strategy you're trying to take.

[jfpedroza]

I agree that adding more opt-outs makes it easier not use the tool properly.

I hadn't thought about making them top-level as it didn't seem like the "proper" way. I think that could work. We'll be exploring that and come back.

[costaraphael]

Hey @sasa1977 ! Thanks for building this first of all ! 💜

I think I've found a use-case for something like this. I've been using boundary in an application that uses generated modules from protobuf definitions, which means I have no control over the source code for these modules.

My initial approach was to use a namespace like Pb to generate the modules, and then define a Pb boundary with checks disabled, and while that works, having this namespace breaks the decoding of the Any type: https://hexdocs.pm/protobuf/Protobuf.JSON.html#module-google-protobuf-any

This means I need to have a bunch of top-level modules where I don't really have control over their code and can't assign them to a boundary.

It would be great if I could disable this warning, either globally or on specific folders/module prefixes.

[sasa1977]

Hey, thanks for mentioning this.

I'm not quite sure how any with protobuf json works, but my first thought is that no library should generate a bunch of top-level modules, because this pollutes the names at the highest level. Not to mention that there might be conflicts with other top-level modules, some of which you might be out of our control (e.g. from 3rd party libs).

In my view, a library generating modules should provide some way for the client code to specify the namespace. Supporting disabled warnings for the unclassified modules feels like we're solving this in the wrong place, adding a feature to boundary to fix a deficiency in other libs.

I might even be persuaded to support this, but first I'd start by checking with the protobuf maintainers if any can be used with a custom namespace.

[costaraphael]

Yeah, after sleeping on this I agree with you, this is probably something that could be handled at the protobuf library level. I'll start a conversation about it with them.

Thanks for the thoughtful response!