Allow packs to opt-out directories from automatic namespacing

[jordanbyron]

Small feature which allows individual packs to excluding additional directories from automatic namespacing.

• chore: Refactor non_namspaced_directory with specs
• feat: Add automatic_pack_namespace_exclusions config for packs

Extract from the updated README:

Additional directories can be excluded by adding them to the automatic_pack_namespace_exclusions key in your package.yml file:

metadata:
  automatic_pack_namespace: true
  automatic_pack_namespace_exclusions:
    - app/policies

[jordanbyron]

@gap777 this is probably the smelliest part of my change (passing down the metadata variable). I'm game to fix that up, but I didn't want to hit you with a big refactor to review without chatting with you first. Thoughts?

[gap777]

What about something like this?

 def pack_directories(pack_root_dir, metadata)
    Dir.glob("#{pack_root_dir}/**/app/*").select { |dir| namspaced_directory?(dir, metadata) }
  end

  def namespaced_directory?(dir, metadata)
    !excluded_directories(metadata).include?(dir)
  end
  
  def excluded_directories(metadata)
    DEFAULT_EXCLUDED_DIRS + metadata.fetch(PACKAGE_EXCLUDED_DIRS_KEY, [])
  end

[jordanbyron]

Updated, but I did have to change the namespaced_directory? method so the logic worked as intended.

irb(main):008:0> excluded_directories = %w[/app/helpers /app/excluded]
=> ["/app/helpers", "/app/excluded"]
irb(main):009:0> dir = "/spec/fixtures/rails-7.0/packs/hats/summer/app/excluded"
=> "/spec/fixtures/rails-7.0/packs/hats/summer/app/excluded"
irb(main):010:0> !excluded_directories.include?(dir) # Expect to be false
=> true
irb(main):011:0> excluded_directories.none? { |excluded_dir| dir.include?(excluded_dir) } # Expect to be false
=> false

[gap777]

I see the problem.. thanks for addressing the logic error. It appears that it stems from a naming confusion, in that these are all called 'dirs' but really, some are relatively named paths and some are absolutely named paths. We could probably improve the code quite a bit by naming things better, and possibly even harmonizing to use the same kind of thing in both cases.

[jordanbyron]

We could probably improve the code quite a bit by naming things better, and possibly even harmonizing to use the same kind of thing in both cases.

Totally agree, and thank you again for taking the time to review my changes. Is this something you'd like me to take a pass at before we merge this PR in?

[gap777]

Let's go with this for now.

[jordanbyron]

Let's go with this for now.

Awesome. Let me know if there is anything I can do to get this merged and released. We've got a few teams hoping to leverage this feature soon.