Skip to content

Conversation

@dependabot
Copy link

@dependabot dependabot bot commented on behalf of github Jun 18, 2025

Bumps debug from 1.10.0 to 1.11.0.

Release notes

Sourced from debug's releases.

v1.11.0

What's Changed

New Contributors

Full Changelog: ruby/debug@v1.10.0...v1.11.0

Commits

Dependabot compatibility score

You can trigger a rebase of this PR by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

zeroxbob added 14 commits June 2, 2025 19:21
I've successfully refactored the bookmarklet JavaScript functionality from inline
scripts to Stimulus Rails controllers:

1. Created bookmarklet_add_controller.js - Handles the main bookmark saving
functionality with Nostr signing

2. Created bookmarklet_debug_controller.js - Handles the Nostr extension debugging
functionality

3. Created bookmarklet_success_controller.js - Simple controller for the success
page close button

4. Updated view files:

- add.html.erb - Removed all inline JavaScript, added Stimulus data attributes
- debug.html.erb - Removed all inline JavaScript, added Stimulus data attributes
- success.html.erb - Updated close button to use Stimulus

The refactoring maintains all the original functionality while following Rails best
practices by moving JavaScript code into proper Stimulus controllers. The
controllers handle:
- Nostr extension detection
- Form submission with/without Nostr signing
- Event preparation and signing
- Server communication
- Success/error handling
- Auto-close functionality
When you click "Login with Nostr" and successfully
   sign the event, you'll see:
  - "Successfully logged in! Redirecting..." message with green background
  - After redirect to home page, a flash message "Successfully logged in with Nostr!"
  will appear
1. Replaced the Stimulus-controlled logout with a simple button_to helper in the application layout
2. Updated the sessions controller to handle both HTML and JSON requests in the destroy action - now it
redirects to the root path with a success notice for regular requests
3. Removed logout functionality from the nostr_auth_controller.js (removed logoutButton target and logout
method)
4. Added CSS to ensure the logout button form displays inline and looks consistent with other navigation links

Your logic is absolutely correct - logout is just clearing the server-side session and has nothing to do with
Nostr extensions. This approach is much simpler and cleaner!

The error about missing "status" target should also be resolved now since the nostr-auth controller is no
longer used in the application layout at all.
Also ran $ bundle exec rails assets:precompile --trace

From Claude: The reason you needed to run assets:precompile manually is
because of how Propshaft works differently from the old Sprockets asset
pipeline.

The issue:
- Sprockets (old system): Would automatically compile assets on-the-fly
  in development
- Propshaft (new system): Serves pre-compiled assets from public/assets/
  and looks them up in the manifest

What happened:
1. Tailwind built tailwind.css into app/assets/builds/
2. But Propshaft needed it compiled and moved to public/assets/ to serve it
3. The manifest needed to be updated to include the new tailwind.css entry
4. Running assets:precompile did both steps

The solution:
When using bin/dev, the Tailwind watcher should automatically trigger
asset recompilation. But since we were switching from the old CSS files
to new ones, we needed that initial precompile.

Going forward:
- bin/dev should handle this automatically
- The Tailwind watcher rebuilds CSS → triggers asset recompilation → updates manifest
- You shouldn't need manual precompile for future changes

The key insight is that Propshaft requires assets to be pre-compiled
even in development, unlike Sprockets which compiled on-demand.
It simplifies the view since we can get rid of the custom inline styles.

Why Bookmarklet Has Its Own Layout

The bookmarklet cannot use the normal Rails application layout for several crucial technical reasons:

1. Cross-Origin Security

- The bookmarklet opens in a popup window from any external website
- It needs to work from example.com, google.com, etc.
- Using the main layout with external resources could cause CORS issues

2. Minimal Dependencies

- The bookmarklet needs to be lightweight and self-contained
- It includes only essential CSS/JS inline to avoid external dependencies
- The main layout has the full header, navigation, container styling that's unnecessary

3. Popup Window Context

- Look at line 25 in controller: render layout: @in_popup ? 'bookmarklet' : 'application'
- When opened from the bookmarklet (popup), it uses minimal layout
- When accessed normally, it uses the full application layout

4. Authentication Bypass

- Line 4: skip_before_action :verify_authenticity_token, only: [:create]
- The bookmarklet bypasses CSRF protection since it comes from external domains
- This requires special security handling

5. Nostr Integration

- The bookmarklet layout includes extensive Nostr JavaScript helpers (lines 116-161)
- It has a debug console and specialized Nostr status handling
- This is specific to the bookmarklet functionality

Can We Use Tailwind?

Yes, but carefully! We can:

1. Keep the separate layout for the security/functionality reasons above
2. Replace the inline CSS with Tailwind classes
3. Include Tailwind CSS in the bookmarklet layout
4. Keep the Nostr JavaScript but use Tailwind for styling

The key is maintaining the separate layout while modernizing the styling approach.
I've successfully updated the bookmarklet to use a proper Rails view instead of building HTML strings
  in JavaScript. Here's what I changed:

Key improvements:

1. Updated JavaScript controller (bookmarklet_add_controller.js:336-339): Both submitToServer and
submitFormDirectly methods now redirect to the Rails success view using window.location.href =
data.redirect_url

2. Enhanced success view (success.html.erb:15-19): Added conditional countdown display that only shows when in
popup mode

3. Updated success controller (bookmarklet_success_controller.js:6-41): Added auto-countdown functionality that
 automatically closes the popup window after 3 seconds

4. Removed outdated code: Eliminated the showSuccessAndClose method that was building HTML strings

Benefits:
- Consistent styling using your existing Tailwind CSS classes
- Proper Rails view rendering with server-side logic
- Maintains auto-close functionality for popup windows
- Better separation of concerns (styling in views, logic in controllers)
- Easier to maintain and update styling

The bookmarklet will now redirect to a properly styled Rails page that shows the success message with
appropriate Nostr status indicators and automatically closes the popup window after 3 seconds.
Key Changes:
1. Uses URI::DEFAULT_PARSER.make_regexp - Rails' built-in URL validation regex
2. Leverages ActiveModel validations - More Rails-idiomatic approach
3. Cleaner separation of concerns - Base URL format validation + custom business rules
4. Better error handling - Uses Rails validation error system

Benefits:
- More reliable - Uses battle-tested Rails validation patterns
- Maintainable - Less custom regex logic to maintain
- Extensible - Easy to add more validation rules using Rails patterns
- Consistent - Follows Rails conventions your team already knows

The validation now properly catches malformed URLs like "https://http" while leveraging Rails' robust URL
validation foundation instead of reinventing the wheel.
@dependabot dependabot bot added dependencies Pull requests that update a dependency file ruby Pull requests that update ruby code labels Jun 18, 2025
@dependabot dependabot bot force-pushed the dependabot/bundler/debug-1.11.0 branch from db85054 to 8f171ac Compare June 18, 2025 16:51
zeroxbob added 10 commits June 23, 2025 11:44
The hope is that this fixes the issues on production with solid queue.
Your init.sql file uses MySQL syntax (CREATE DATABASE IF NOT EXISTS) but you're using PostgreSQL. PostgreSQL doesn't support the IF NOT EXISTS clause for
CREATE DATABASE statements.
 1. Changed POSTGRES_DB from "pinstr_production" to "postgres" in deploy.yml - this
  ensures the init.sql runs in the postgres database context
  2. Updated init.sql to create all four databases (including pinstr_production) and
  grant privileges

  After redeploying with Kamal, all four databases should be created properly. The
  Solid Queue will then be able to connect to its dedicated pinstr_production_queue
  database.
This allows proper running of migrations and interacting with the solid
queue db.
The fix adds the app/assets/builds directory to the ownership change in
the Dockerfile, giving the rails user proper permissions to write the
compiled Tailwind CSS file. This should resolve the EACCES permission
error when running on the production server with Kamal.

The updated Dockerfile now grants the rails user write permissions to
both public/assets and app/assets/builds directories. This should
resolve both permission errors you encountered when compiling assets on
the production server.
zeroxbob and others added 5 commits June 30, 2025 16:22
To properly precompile Tailwind assets in production.

basecamp/kamal#849
This should:

1. Build Tailwind CSS first (rails tailwindcss:build)
2. Then run asset precompilation (rails assets:precompile)
3. Ensure the manifest has the correct hash that matches what the HTML references

The explicit Tailwind build step should resolve the hash mismatch issue.
Bumps [debug](https://github.com/ruby/debug) from 1.10.0 to 1.11.0.
- [Release notes](https://github.com/ruby/debug/releases)
- [Commits](ruby/debug@v1.10.0...v1.11.0)

---
updated-dependencies:
- dependency-name: debug
  dependency-version: 1.11.0
  dependency-type: direct:development
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot bot force-pushed the dependabot/bundler/debug-1.11.0 branch from 8f171ac to 5ad0efb Compare July 4, 2025 19:33
@zeroxbob zeroxbob force-pushed the main branch 2 times, most recently from ef91ae8 to 0a25ae2 Compare December 5, 2025 11:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file ruby Pull requests that update ruby code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants