App/javascript feels like the wrong name for that directory

A May Of WTFs
#6

This used to irk me as well, but I had an “aha” moment when I read this blog post Importing images with Webpacker - rossta.net

Isn’t weird to put images and css in a folder called “javascript”? Depends. If you consider, from webpack’s perspective, everything is a JavaScript module, it may not be so strange. Otherwise, it’s possible to rename app/javascript or place your images elsewhere. More on that below.

1 Like
#7

Well at compile-time, I think the ruby based SASS/SCSS assets are much faster than Webpack–and that almost goes without saying, since I don’t think JS is nearly as fast as Ruby and Webpack relies upon so many plugins to actually act as the “asset pipeline”.

I definitely get frustrated by how long it takes Webpack to just confirm that 99% of my assets haven’t changed when I make a small design tweak.

Full disclosure though, I feel like Webpack could be much more highly optimized than it is out of the box, and then it would be a decent solution. Sprockets feels like it was relatively lean compared to the massive dependencies Webpack requires to function.

2 Likes
#8

I do agree that can be frustrating.

The real issue for this topic though is the naming of the app/javascripts directory. The clear reason is that Rails still expects you to use Sprockets for css and images.

#9

I was actually under the impression the reason it’s the app/javascript was just for compatibility with people who have apps still partially using the asset pipeline and can’t fully upgrade to web pack right out of the upgrade to Rails 6/Webpack 4/5.

I still use some core/vanilla javascript and having app/javascript/js or app/javascript/javascript sucks… I settled on app/javascript/vanilla for now.

1 Like
#10

I wish we could keep the old format: assets/stylesheets assets/javascripts etc.

for Webpack as well.

I thought that was a tidy and intuitive way to organize a project. Though I realize it doesn’t necessarily play well with some JS frameworks.

1 Like
#11

my vote would go to app/frontend

6 Likes
#12

If you only want to use webpack, you can remove sprockets and use app/assets as your directory. It’s configurable with webpacker.

I find that the folder being named javascript suggests how it is intended to be used by default. Don’t like it or also want to include other assets? You can rename it.

1 Like
#13

Have you tried enabling “chunks”? I’ve found that webpacker became much faster and smarter than the asset pipeline when compiling only the changes of the code you’re working on with this set up.

#14

I’ve renamed app/javascripts to app/assets_webpack in the projects where I’ve used webpack, because I didn’t like putting css in a “javascripts” folder. This also puts both assets directories next to each other in TextMate which is useful.

I haven’t fully migrated any projects to use exclusively webpack yet.

#15

I think documentation, such as improvements to the Rails guides, could help here. We could help address questions about setup, such as directory names and layout, both for developers that prefer the Rails default (Webpacker for JS, Sprockets for CSS and images) and the “all-in” on Webpacker approach.

#16

I have tried chunks, and chances are good I’m just not using them correctly. It does still take an impressive amount of time for webpack to only compile and then review all of the chunks to see what’s changed.

I’ll look into this more though. It has been extremely tempting to switch back to the asset pipeline for SCSS/images. I don’t use utility frameworks like Tailwind, so I don’t think I would really be losing anything by doing this.

#17

Noticing a lot of crossover between this and Sprockets abandonment.

1 Like
#18

This has my vote as well. It makes a lot of sense in a SPA, maybe less so with javascript sprinkles.

Frequently WTFed WTFs
#19

That would be very misleading. /views holds the html, which is the frontend

#20

Finding a good name is hard. Perhaps we could use “packs” as the directory name, since they are the common name that maps between Rails and all the frontend-that-isnt-views?

E.g.:

app/javascript/packs/application.js
app/javascript/components/hello.js
app/javascript/styles/hello.css

To:

app/packs/entries/application.js
app/packs/components/hello.js
app/packs/styles/hello.css
#21

I think the primary pressure to rename app/javascript comes from when you’re doing SPA-style, you want Webpack for everything, and you don’t want to use the asset pipeline at all. As Pablo suggested, I think it’s completely valid to have app/assets (or whatever you like) taken over by Webpack.

But what we have now, where Webpack by default is for JS compilation, the Asset Pipeline for css/images/etc, is not a concession to some legacy setup. It’s the legitimate choice based on how I like to build applications. We’re building a new app at Basecamp called HEY, and it’s running this combo, and we’re very happy with that.

THAT SAID, I’d be happy to support a dialect in the rails new setup where you essentially say “I want Webpack to own all my assets”, and then we provide a fork in the road there. --webpack-exclusive or whatever you’d like. Then we wouldn’t configure Sprockets, we wouldn’t have app/javascript.

Which comes to an even larger point: Rails is a very big tent. We’re never going to have everyone agree on the entire toolset, when we’re this ambitious in how much Rails should have a say in.

So that leaves us with a much easier path: The default will be the creator’s prerogative (informed/influenced/assisted by a broad community), and then we’ll codify major dialects with nicely paved options that make it easy for us all to enjoy the tent together! We don’t have to agree on whether Webpack is better at image compilation than sprockets in order to share and collaborate on Active Record. And so on.

In short: Let’s try to build consensus around a webpack-only dialect. What should the directory be called? How do we remove sprockets best by default? And then we need a champion or a group interested and dedicated to maintaining this dialect.

12 Likes
#22

What I would propose is:

  • Put webpacker files in app/assets instead of app/javascript
  • Edit webpacker.yml and set the source_path to app/assets
  • Add necessary CSS imports in application.scss when generators add stylesheets when webpacker is loaded but sprockets is not.
  • Uncomment images related code in application.js

About the flag using rails new --skip-sprockets could trigger these changes.

2 Likes
#23

Perhaps not as cute, but we’ve used app/webpack_assets/ instead. Fairly non-controversial on its face, and honestly, if the immediate future supports both webpack and sprockets working in tandem, why muddy the waters not calling out the directory explicitly?

#24

Or, I guess:

  • app/assets/webpack
  • app/assets/sprockets

To be collapsed back down to app/assets once we have only one option.

3 Likes
#25

I see my fellow developers are changing default to app/frontend.

The problem I am getting in rails 6 is the autoload paths now should --except app/frontend too.

Autoloading and Reloading Constants (Zeitwerk Mode) — Ruby on Rails Guides

Then I have to config Zeitwerk to unload that folder unconventionally. Because in JS world kebab-case naming makes sense.