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

Add shakapacker.yml as the secondary source for asset_host and relative_url_root #376

Merged
merged 11 commits into from
Dec 22, 2023

Conversation

ahangarha
Copy link
Contributor

@ahangarha ahangarha commented Nov 7, 2023

Summary

This is a follow-up PR, implementing what has been discussed here.

Pull Request checklist

  • Add/update test to cover these changes
  • Update documentation
  • Update CHANGELOG file

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

  • Do we actually use 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.

@ahangarha ahangarha changed the base branch from master to make-compilation-stale-on-host-change November 7, 2023 14:15
@ahangarha ahangarha marked this pull request as draft November 7, 2023 14:39
@ahangarha ahangarha requested a review from Judahmeek November 8, 2023 13:33
@ahangarha ahangarha self-assigned this Nov 8, 2023
@justin808
Copy link
Member

@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.

@G-Rath
Copy link
Contributor

G-Rath commented Nov 17, 2023

I think it's useful giving it a dedicated changelog entry because this is a feature whereas the other PR is a bug

@ahangarha
Copy link
Contributor Author

ahangarha commented Nov 17, 2023

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.

@ahangarha ahangarha changed the base branch from make-compilation-stale-on-host-change to master November 17, 2023 10:05
@ahangarha ahangarha changed the title Add asset_host and relative_url_path to config file Add asset_host and relative_url_root to config file Nov 17, 2023
@ahangarha ahangarha force-pushed the fix-asset-host-and-relative-url-path-config branch 4 times, most recently from a627eb4 to 903b659 Compare November 25, 2023 07:45
@ahangarha ahangarha marked this pull request as ready for review December 2, 2023 20:07
@ahangarha ahangarha force-pushed the fix-asset-host-and-relative-url-path-config branch from b5fef8b to 2677f81 Compare December 3, 2023 08:46
Copy link
Member

@justin808 justin808 left a comment

Choose a reason for hiding this comment

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

Seems like we need

  1. Migration instructions
  2. Updated README?

CC: @ahangarha @G-Rath

ENV.fetch("SHAKAPACKER_ASSET_HOST", ActionController::Base.helpers.compute_asset_host)
end

def relative_url_root
Copy link
Member

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?

@G-Rath @ahangarha

Copy link
Contributor Author

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 the relative_url_root to the publicPath, they went with a public_root configuration instead (which publicPath does use) rails/webpacker#1848

So 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).

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@G-Rath G-Rath left a 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

@ahangarha ahangarha changed the title Add asset_host and relative_url_root to config file Add shakapacker.yml as the secondary source for asset_host and relative_url_root Dec 9, 2023
@ahangarha ahangarha force-pushed the fix-asset-host-and-relative-url-path-config branch from 9610fe8 to dd6484e Compare December 18, 2023 15:41
Comment on lines 119 to 124
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
Copy link
Contributor Author

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
Copy link
Member

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?

Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

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

Ca fetch return a ""?

Copy link
Contributor Author

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.

spec/backward_compatibility_specs/compiler_spec.rb Outdated Show resolved Hide resolved
end

context "without ActionController::Base.helpers.compute_asset_host returing any value" do
it "returns an empty string" do
Copy link
Member

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?

Copy link
Contributor Author

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.

@ahangarha ahangarha requested a review from justin808 December 21, 2023 15:41
@justin808 justin808 merged commit 1cb8e16 into master Dec 22, 2023
82 checks passed
@justin808 justin808 deleted the fix-asset-host-and-relative-url-path-config branch December 22, 2023 21:16
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.

3 participants