Allowing of more generalized public namespacing

[bschrag620]

To better fit within a typical rails folder structure I feel like there is benefit to allowing the public folder to be the root module within a package. So rather than app/public being the required place for public interfaces, it could help to keep code in the expected place within a rails application if instead the constant was expected to be placed in a Public:: namespace. So taking a typical app/engine folder structure:

app
|- models
|--  concerns
|---  public
|----  publicity.rb
|- services
|-- closed.rb
|--  public
|---  open.rb
...

There is a concern (Public::Publicity) and a service (Public::Open) that are publically available. This feels like it would allow for a more typical rails convention while still nicely enforcing the boundaries between packages.

[alexevanczuk]

Thanks for opening the issue @bschrag620. Right now, we only permit a single public folder - I think this would require multiple public folders.

One workaround you can do right now is to have your public folder essentially just "alias" things in your other folders. So instead of defining the whole thing in your public folder, just creating a public constant that wraps the service or concern. It's a bit of extra boiler plate but otherwise should solve it for you.

Long term, we've thought ideally that we could allow something to be public with a comment at the top of the file. This would give full flexibility to define what's public.

Let me know what ya think!

[bschrag620]

My suggestion would be to allow for multiple public folders. It would also mean that the public objects would begin within a Public:: namespace. This does have a side benefit that when doing code review it is more easily known that it is a publicly defined constant but perhaps that is a bit redundant given the privacy checks in packwerk. I do like the idea however of public declaration in a file. The motivation for my suggestion was to allow for file structure to still follow the usual patterns which the commenting approach would allow for.

…

On Sat, Sep 16, 2023, 7:41 AM Alex Evanczuk ***@***.***> wrote: Thanks for opening the issue @bschrag620 <https://github.com/bschrag620>. Right now, we only permit a single public folder - I think this would require multiple public folders. One workaround you can do right now is to have your public folder essentially just "alias" things in your other folders. So instead of defining the whole thing in your public folder, just creating a public constant that wraps the service or concern. It's a bit of extra boiler plate but otherwise should solve it for you. Long term, we've thought ideally that we could allow something to be public with a comment at the top of the file. This would give full flexibility to define what's public. Let me know what ya think! — Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFOXORLLH4SDYPQ3QIWA73DX2WUBZANCNFSM6AAAAAA42OH5DQ> . You are receiving this because you were mentioned.Message ID: <rubyatscale/packwerk-extensions/repo-discussions/34/comments/7021715@ github.com>

[alexevanczuk]

You should still be able to have public objects begin with a Public:: namespace with a single public folder with aliasing. For example, imagine we have:

app/ # this is autoloade
  public/ # this is autoloaded
    public/ # this defines the namespace
      my_constant.rb # this defines `Public::MyConstant = MyConstant`
  services/
    my_constant.rb # this defines `MyConstant`

I definitely agree with you about optimizing for the standard file structure convention. At Gusto we observed various problems (some mechanical, some cultural due to going against convention) related to the public folder. I think the magic comment would be the easiest thing to support long-term since it will be the most invisible to other systems. If you'd like to take a stab at implementing this, I'd be happy to support!

[bschrag620]

Thanks @alexevanczuk , I'll checkout the repo and start to see what might make sense in terms of an implementation here.

[alexevanczuk]

Okay sounds good @bschrag620 ! Please let me know how I can help.

Also cc @ngan who is very interested in migrating from public folders to magic sigils (cc @shageman too)

The main thing I'd want us to get right is to allow a file to be parsed once to determine if it's public rather than multiple times. Easiest way to do this with the existing packwerk architecture would probably be to just have the packwerk privacy checker store a memoized hash of file to whether it's public. Then whenever any other system wants to know if something is public, they can ask the Packwerk::Privacy::Checker if the file is public. Not actually sure if this is the best design but open to ideas.

[bschrag620]

@alexevanczuk Hopefully this is a good starting point. Let me know what you think!

[alexevanczuk]

Amazing, thanks for kicking this off @bschrag620 . cc @ngan, @shageman who may be interested in ensuring this makes sense and works in the Gusto modulith!