Follow app/javascript/application.js convention from Rails 7

[dhh]

To ensure compatibility across the different JavaScript bundler options supported by Rails 7 (like esbuild-rails), we need to use the same entry point by default. That entry point is going to be app/javascript/application.js. You can of course continue to change that in your webpacker.yml config, but by sharing the same default, we can make other generators work out of the box.

[mcmire]

What's the reasoning behind this change? I feel like app/packs (or something like it) is a good name because it communicates to developers that it's not just JavaScript that can be bundled, it's also CSS, images, SVGs — you name it. I realize what can be bundled is wholly dependent on the bundler you use, but even esbuild supports bundling CSS. So couldn't this possibly be confusing? Or is the idea that most developers will want to continue to use app/assets for CSS, images, SVGs, etc. and the idea of using a JavaScript bundler for this is already confusing enough?

[dhh]

app/javascript is what Webpacker has used in its entire existence of release. The new importmap approach that'll be the default in Rails 7 uses the same, then app/assets for anything else. This default ensures that all the default integrations can work off the same entry point, and for those who want something else, the webpacker.yml file let's them change it.

[crawler]

So the "my_component.js" will be processed as the entry point. What if you have files that you don't want to be entry points, at least because of compile performance?

You will need to set up something like app/javascript_lib ?

[dhh]

@crawler Entrypoints are limited to the top level, so app/javascript by default. app/javascript/components (or whatever) is where you'll put anything not a entry point.

[crawler]

@dhh I see, not sure if this is suitable for everyone. Because at least we use directory structured entry points, as well as some custom libs. But anyway, this behavior can be changed with configuration/tweaking.
BTW i fixed github actions workflow in #3150

[dhh]

Yeah I don’t think we will find something that works for everyone in all cases. But Webpacker is quite flexible with the setup it has now. Easy to change!

[TylerRick]

FYI, when I tried this, I noticed that webpack ended up searching for files recursively under source_entry_path (app/javascript), so it ended up with >100 entrypoints listed under "entry":

  "entry": {
    "application": "app/javascript/application.js",
    "common/array/chunk": "app/javascript/common/array/chunk.ts",
    "common/http_interceptors/add_csrf_token": "app/javascript/common/http_interceptors/add_csrf_token.ts",
    "common/invertMap": "app/javascript/common/invertMap.tsx",
    "common/utils": "app/javascript/common/utils.ts",
     …
  },

Unless there's some way to make it only look at the top level of app/javascript without recursing, or unless I'm just doing something wrong, then this may not be such a good idea after all...

As a workaround, I ended up changing the config back to a "dead-end" (no subdirs for it to recurse) directory:

  source_entry_path: entrypoints

[dhh]

Yes there’s a change to the JS glob that goes in the @rails/webpacker module only to look at the top level. Not nested.

[TylerRick]

Thanks, that did the trick.

(yarn add https://github.com/rails/webpacker.git instead of locked to rc.5)

[kimyu92]

⚠️ This change is huge for those who choose to upgrade to webpacker 6, leave their pack file in subdirectories and didn't want to change source_entry_path from packs to /

In that case,
// This behavior retained
app/javascript/packs/application.js

// Missing pack file
app/javascript/packs/foo/fooPack.js
app/javascript/packs/foo/fooPack.scss