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

Default namespace support #27

Merged
merged 2 commits into from
Apr 1, 2022
Merged

Conversation

mclark
Copy link
Contributor

@mclark mclark commented Mar 25, 2022

As described in Shopify/packwerk#186, Zeitwerk supports default modules for root directories. This pull request adds support for this capability to ConstantResolver.

I opted to keep this as simple as possible and just deal with Strings for the constant names. The resolver appears to inherently only be concerned with Strings anyway so it seemed to be consistent to me versus holding references to Module instances. If the provided load paths hash points to modules, as it does in the hash returned by Zeitwerk::Loader#root_dirs, then we just call to_s on them anyway.

For detecting whether the load paths are a hash or not, I duck check to see if the argument responds to :transform_keys. I'm not sure if this is ideal, maybe others have ideas?

I've also tested this change in concert with the Packwerk changes on this branch against the GitHub monolith to ensure things behave as expected. The GitHub monolith is old and has a few root directories which have default namespaces other than Object so this is a decent test case. I'm pleased to report the expected violations were detected resulting much more accurate reports.

cc @exterm @rafaelfranca from our discussions on Shopify/packwerk#186

@@ -119,6 +119,15 @@ def config

private

def coerce_load_paths(load_paths)
load_paths = Hash[load_paths.map { |p| [p, "Object"] }] unless load_paths.respond_to?(:transform_keys)
Copy link
Contributor

Choose a reason for hiding this comment

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

At some point I'd like to introduce sorbet to this codebase to make these things a little more obvious, but this is fine for now

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ha, yeah, I was thinking the same thing but that's a PR for another day 😄

load_paths = Hash[load_paths.map { |p| [p, "Object"] }] unless load_paths.respond_to?(:transform_keys)

load_paths.transform_keys! { |p| p.end_with?("/") ? p : p + "/" }
load_paths.transform_values! { |ns| ns.to_s.delete_prefix("::") }
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you elaborate on why this is necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is an attempt to ensure all default namespace strings are formatted the same and in the way as expected by the resolve method.

Copy link
Contributor

Choose a reason for hiding this comment

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

👍🏼

@exterm exterm requested a review from gmcgibbon March 29, 2022 14:35
@mclark mclark force-pushed the default-namespace-support branch from 5d1d8dc to 32f964a Compare March 29, 2022 15:40
@mclark
Copy link
Contributor Author

mclark commented Mar 29, 2022

Oops! Bad etiquette, I should not have force pushed after a review ☝️ All that was doing was fixing a style linting error, adding a comma to the last element of an array.

@exterm
Copy link
Contributor

exterm commented Mar 30, 2022

Let's see if we can get a second review within a few days, but if not, I'm OK shipping this as is

@exterm exterm requested a review from rafaelfranca March 30, 2022 14:21
@exterm exterm merged commit ba7fd11 into Shopify:master Apr 1, 2022
@mclark mclark deleted the default-namespace-support branch April 1, 2022 14:23
@shopify-shipit shopify-shipit bot temporarily deployed to production April 1, 2022 17:40 Inactive
@mclark mclark mentioned this pull request Apr 1, 2022
7 tasks
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.

2 participants