current.txt

|- app
|  |- assets
|  |  |- javascripts
|  |  |  |- popover.js
|  |  |- stylesheets
|  |  |  |- popover.scss
|  |- helpers
|  |  |- ui_popover.rb
|  |- views
|  |  |- styleguide
|  |  |  |- popover.html.erb
|- test
|  |- javascripts
|  |  |- unit
|  |  |  |- popover_test.js
|  |- unit
|  |  |- helpers
|  |  |  |- ui_popover_helper.rb

different repo...
|- components
|  |- popover
|  |  |- popover.sketch
|  |  |- README.md

ideal.txt

|- components
|  |- popover
|  |  |- popover.js
|  |  |- popover.scss
|  |  |- popover.rb
|  |  |- README.md
|  |  |- test
|  |  |  |- popover-test.js
|  |  |  |- popover_test.rb

👍 from me. This structure is a direct representation of the package's purpose: provide components. If we were talking about reorganizing Shopify or some other Rails app that isn't consumed as a package, then I would say no.

I don't think the argument for the Rails organization paradigm applies here. Even if this package becomes a Rails app, its purpose remains to provide components and we worst case scenario contributing Rails devs are confused for some period of time. We'd still be walking away with new knowledge we'd otherwise miss out on if following the current pattern.

I’ve previously worked on projects (caveat: not Rails) that made this switch. The biggest vote of confidence was from the lead dev who set up the original structure, but wasn’t deeply involved in the change. He started up a new project (we built lots of projects with the same scaffolding) and immediately fell in love with the change.

Beyond anecdotes, I sympathize with this being different from Rails conventions. OTOH, in terms of front-end, the paradigm shift has already happened. Components (not HTML/CSS/JS) are the primary way of factoring an interface. It’s not a blocker of course, but the current way is a source of conceptual friction. The assets package is a great opportunity to re-align things. I’m in favour of pursuing this at least to the next stage, where we can see in more detail what the implications are.