On-demand type generation not working when using Docker #13
Replies: 5 comments
-
Hi Erik! Thanks for reporting. It would be interesting to know if in your app the following condition is met when the gem is loaded. You can try opening the gem by running The most likely scenario is that this condition is
That makes sense, because it's the |
Beta Was this translation helpful? Give feedback.
-
Hi Máximo, thanks for the quick response! Following your steps, I can see that the initializer "types_from_serializers.reloader" do |app| I'm not sure if this is due to something being odd with my app's set up that leads to an incorrect load order, and this hook getting registered too late. But after reading this thread, I tried changing the hook mentioned above to: config.after_initialize do |app| and then everything works as expected. I don't know enough about the inner workings of Rails to say if this is a issue with this gem or the problem is in my app. |
Beta Was this translation helpful? Give feedback.
-
That thread suggests that by the time the railtie is loaded, You could try debugging to see in which order the code loads in your app. Another thing that might be affecting how things load is whether you have this gem in a non-standard group in your Gemfile or something that causes this line not to load the gem: Bundler.require(*Rails.groups) |
Beta Was this translation helpful? Give feedback.
-
Hi, apologies the load order might have been a false flag, using docker I struggled a bit to patch the installed version of the gem inside the container but I have now succeeded with that. Putting debug prints in there I can see the initializer firing as expected. I have now put some console outputs around the generator class, and I can see that changes.updated? is always false. So it gets to this stage, but never regenerates anything because of that. So the problem seems to be the changes aren’t being successfully tracked, and I’m not sure exactly why. This is where it gets tricky because if look in the rails console, I can see entries in the Possibly the bug could be related to the fact that I've changed the default folder to: config.serializers_dirs = [Rails.root.join("app/typed_serializers").to_s] but this has not caused any other issues. If there’s nothing else obvious to try, nothing to worry about as it works pretty well with this hook set up as a workaround Rails.application.reloader.to_prepare do
TypesFromSerializers.generate(force: true)
end |
Beta Was this translation helpful? Give feedback.
-
It could be related to the volume that is mounted, and whether Thanks for sharing a workaround, it should be helpful for other folks using Docker in development. |
Beta Was this translation helpful? Give feedback.
-
bundle update types_from_serializers
.Description 📖
On demand generation on change not working, but I found a workaround that does the job for now.
Reproduction/Logs 🐞📜
Hi Máximo, thanks for another awesome gem.
I'm struggling a bit with the autogeneration of types. It seems to be initializing properly, and indeed tracking changes too.
If I make a change to a serializer, and then check the output of running
Rails.application.reloaders
in my console, I get the following output:So the tracking does seem to be working, but it nothing is ever re-generated, unless I explicitly call
TypesFromSerializers.generate_changed
in the rails console, then it works.So I then tried forcing it by adding another hook in my initializer:
But at this stage, it doesn't seem to be aware of file changes. Like this hook has a different context to my rails console. So nothing happens.
As a workaround for now I changed this hook to:
And it works, and it's fast enough re-generating everything that it's an acceptable workaround.
So that's my issue, and I wanted to ask you if you have an idea why this may be happening? Just to mention I have also installed the
listen
gem.Cheers!
Beta Was this translation helpful? Give feedback.
All reactions