-
-
Notifications
You must be signed in to change notification settings - Fork 95
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
Add shakapacker.yml as the secondary source for asset_host and relative_url_root #376
Add shakapacker.yml as the secondary source for asset_host and relative_url_root #376
Conversation
@G-Rath I think we just need one PR for all this work. @ahangarha if @G-Rath agrees, please consolidate the comments into this PR and change the base to main/master. |
I think it's useful giving it a dedicated changelog entry because this is a feature whereas the other PR is a bug |
I initially aimed to add this to the previous PR but then I thought it better to keep it separate to make a decision about it independently. Since this PR is on top of the #364 PR, I would propose merging that PR first and then merging this one. This is why I made this PR as a draft to prevent merging. |
a627eb4
to
903b659
Compare
b5fef8b
to
2677f81
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ENV.fetch("SHAKAPACKER_ASSET_HOST", ActionController::Base.helpers.compute_asset_host) | ||
end | ||
|
||
def relative_url_root |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a public API?
Do we need docs explaining this change?
What is the migration if somebody used this ENV: SHAKAPACKER_RELATIVE_URL_ROOT
.
Is this OK as a feature level bump?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for not making it enough clear. I added more explanation in the commit message but it is not enough visible. So let's quote it here:
Remove any references to relative_url_root
Despite being added in webpacker, it never got used. There is no
functionality tied to this configuration and this commit, removes its
references in the code and tests.
and from my private discussion with Judah, he phrased it this way:
Looks like
relative_url_root
was added by rails/webpacker#1236, but instead of doing a follow-up PR to add therelative_url_root
to thepublicPath
, they went with apublic_root
configuration instead (whichpublicPath
does use) rails/webpacker#1848So relative_url_root looks to be dead code.
So, we just inherited this extra unused configuration from Webpacker.
To my understanding, removing this shouldn't have any impact on any project (unless someone has made a customized shakapacker
and used this configuration, but it is very unlikely.
I am not sure if we should keep carrying this code by deprecating it till the next major release. Mentioning this removal in the changelog wouldn't be bad (if needed).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm I'm not quite following, but I think if relative_url_root
is just dead code that's otherwise not actually causing harm, I'd prefer leaving it alone in this PR and then dealing with it separately.
We'll want to do a v8 for switching to package_json
provided that goes well which I'd personally like to have out within the next 6 months so assuming others are happy with that timeline, it should be pretty fine to slap a deprecation warning on relative_url_root
knowing it won't be hanging around for much longer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is also fine to me.
@justin808 I reverted the last commit (of removing relative_url_root
).
We will handle the deprecation later.
If agreed, and there is no other required changes, we are good to go with merge and 7.2 release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is relative_url_root
actually being used though? overall I think if the plan is to deprecate this, we shouldn't change it at all unless it's actually broken
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I agree with you. I don't see any good reason for introducing a new public interface to Configuration
for a deprecated feature.
So I will narrow down this PR to only cover asset_host
and not relative_url_root
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the actual moving of the logic into the configuration was done in #374. This PR was to add some fixes and improve tests. The PR title is misleading.
So I think now that all usages of relative_url_root
goes through a method in Configuration
, that method is the right place for showing a deprecation message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I'd prefer the relative root changes to be done in a dedicated PR, but this seems fine enough to land
Despite being added in webpacker, it never got used. There is no functionality tied to this configuration and this commit, removes its references in the code and tests.
This reverts commit 2677f81. We will address it later.
9610fe8
to
dd6484e
Compare
lib/shakapacker/configuration.rb
Outdated
def asset_host | ||
ENV.fetch("SHAKAPACKER_ASSET_HOST", ActionController::Base.helpers.compute_asset_host) | ||
ENV.fetch( | ||
"SHAKAPACKER_ASSET_HOST", | ||
fetch(:asset_host) || ActionController::Base.helpers.compute_asset_host | ||
).to_s | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only concern with this PR is that I ensure the retuned value is a string in any case. This means if nothing is provided, we get ""
(empty string).
That time, I thought it could help with simplification so that could only check asset_host.empty?
.
I just wanted to raise this again to ensure it is not missed out in the reviews.
ENV.fetch("SHAKAPACKER_ASSET_HOST", ActionController::Base.helpers.compute_asset_host) | ||
ENV.fetch( | ||
"SHAKAPACKER_ASSET_HOST", | ||
fetch(:asset_host) || ActionController::Base.helpers.compute_asset_host |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about fetch(:asset_host).presence
to ensure not blank?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 but no change? why?
@@ -117,11 +117,19 @@ def fetch(key) | |||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ca fetch return a ""?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can. Internally, it runs fetch
on a hash. So it can potentially return ""
or " "
. Though it is very unlikely someone deliberately pass key: ""
in the config file.
Should we consider this in fetch as kind of normalization to ensure we either get a meaningful value or nil? I cannot think of any scenario where in the config we want to pass ""
and not nil
.
end | ||
|
||
context "without ActionController::Base.helpers.compute_asset_host returing any value" do | ||
it "returns an empty string" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why empty strings and not nil?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this was the logic when I was implementing these changes: while calculating digest for the watched assets, I noticed that we may get nil
and at that point, it was strange for me to get nil for asset_host
. I either could convert asset_host
to string to ensure in case of getting nil
, we don't break the logic (for contamination). Later I thought it is better to get empty string right out of asset_host
method if nothing is provided. (Though I forgot to remove the conversion to string in the mentioned code above).
Now I think it is better to return nil
and handle nil
when we want to use it. So I change these lines back to return nil and convert the value into string when we need it.
Summary
This is a follow-up PR, implementing what has been discussed here.
Pull Request checklist
Note
This PR is made on top of make-compilation-stale-on-host-change branch and is supposed to get merged after the PR #364 merge.
Concerns
relative_url_path
? It seems this is a leftover from some old feature which is now completely removed from Shakapacker. If so, we should remove it.