Skip to content
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

Make exports: :all also export subdomains #68

Merged
merged 4 commits into from
Oct 4, 2024
Merged

Conversation

Nezteb
Copy link
Contributor

@Nezteb Nezteb commented Sep 25, 2024

Should resolve #59, though there might be cases I've missed.

Comment on lines +133 to +135
# If the export's `owner_boundary` exports all modules, include sub-modules
%{exports: [{export_module, []}]} ->
String.starts_with?(to_string(export), to_string(export_module))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I understand, this will also export private sub-boundary modules. I find this a bit weird, because we can end up with a scenario that some modules are private to other modules in the common parent boundary, but they can be used by the modules outside of that parent boundary.

So I think we should only include public sub-boundary modules, as mentioned in the last comment in #59.

Bubbling up should also work, for example:

  • if Foo.Bar.Baz is a sub-sub-boundary
  • and Foo.Bar exports Foo.Bar.Baz
  • then exporting all from Foo should also include exports from Foo.Bar.Baz

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even with the updated exports: [Module] test, this logic still seems to work, I think because this function is only looking at the current export and its immediate parent boundary?

I tried writing a few different tests to see if they'd fail but couldn't find any issues with the exported vs private sub-boundaries.

"""
defmodule #{module1} do
use Boundary, exports: :all

defmodule Schemas.Foo do def fun(), do: :ok end
defmodule Schemas.Bar do def fun(), do: :ok end

defmodule SubModule do
use Boundary, exports: :all
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of this I propose exports: [Module], and then we can check that Module.Another (perhaps renamed to Module.Private) is not exported. We also need to expand this test to check if bubbling-up works as expected. This can all be done within the same test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the test to use exports: [Module]!

@@ -1147,13 +1147,27 @@ defmodule Mix.Tasks.Compile.BoundaryTest do
module1 = unique_module_name()
module2 = unique_module_name()

module_test "exporting all modules",
module_test "exporting all modules and sub-modules",
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
module_test "exporting all modules and sub-modules",
module_test "exporting all modules and exports of all nested boundaries",

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated!

@sasa1977
Copy link
Owner

sasa1977 commented Oct 4, 2024

I did some local experiments, and this is still not working properly with respect to sub-sub-boundaries. But it doesn't seem to be the problem of this PR, because I'm able to reproduce the issue on the master too. So I'll just merge this, and then try to resolve it separately. Thanks for the contribution!

@sasa1977 sasa1977 merged commit 5631505 into sasa1977:master Oct 4, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Subdomains unexpected boundary violation
2 participants