Rails: Webpacker 4.2 findet keine Anwendung in /app/public/packs/manifest.json heroku

Lesezeit: 10 Minuten

Rails Webpacker 42 findet keine Anwendung in apppublicpacksmanifestjson heroku
Justin

Ich bin etwas ratlos. Meine lokale Rails-App funktioniert hervorragend mit Webpacker 4.2 und reagiert, aber bei der Bereitstellung in der Produktion gibt es mir das Wunderbare can't find application in /app/public/packs/manifest.json Error.

Folgendes habe ich versucht:

  • Es wurde versucht, Turbo-Link-Details für das Tag des Javascript-Pakets hinzuzufügen/zu entfernen.
  • Javascript-Include-Tag entfernt (nicht sicher, ob dies hilft oder nicht)
  • Stellen Sie sicher, dass ich auf dem neuesten Webpacker bin 4.2
  • lief rake assets:clean && rake assets:precompile manuell auf heroku, nur um sicherzustellen, dass die Dinge gebaut werden.

Übersehe ich einen Build-Schritt oder etwas in der Produktion, das dies verursachen würde? Was bleibt zu prüfen?

Serverfehler:

2019-12-03T15:18:19.022024+00:00 app[web.1]: I, [2019-12-03T15:18:19.021952 #30]  INFO -- : [aa0374eb-bab1-40cc-b40b-6ae3d195e07d] Completed 500 Internal Server Error in 112ms (ActiveRecord: 30.4ms | Allocations: 21296)
2019-12-03T15:18:19.023103+00:00 app[web.1]: F, [2019-12-03T15:18:19.023029 #30] FATAL -- : [aa0374eb-bab1-40cc-b40b-6ae3d195e07d]
2019-12-03T15:18:19.023107+00:00 app[web.1]: [aa0374eb-bab1-40cc-b40b-6ae3d195e07d] ActionView::Template::Error (Webpacker can't find application in /app/public/packs/manifest.json. Possible causes:
2019-12-03T15:18:19.023109+00:00 app[web.1]: 1. You want to set webpacker.yml value of compile to true for your environment
2019-12-03T15:18:19.023111+00:00 app[web.1]: unless you are using the `webpack -w` or the webpack-dev-server.
2019-12-03T15:18:19.023114+00:00 app[web.1]: 2. webpack has not yet re-run to reflect updates.
2019-12-03T15:18:19.023116+00:00 app[web.1]: 3. You have misconfigured Webpacker's config/webpacker.yml file.
2019-12-03T15:18:19.023118+00:00 app[web.1]: 4. Your webpack configuration is not creating a manifest.
2019-12-03T15:18:19.023120+00:00 app[web.1]: Your manifest contains:

{
 "application.js": "/packs/js/application-2a0e2c932678ebbf2ae7.js",
"application.js.map": "/packs/js/application-2a0e2c932678ebbf2ae7.js.map",
"entrypoints": {
 "application": {
"js": [
"/packs/js/application-2a0e2c932678ebbf2ae7.js"
],
 "js.map": [
 "/packs/js/application-2a0e2c932678ebbf2ae7.js.map"
 ]
 },
 "server_rendering": {
 "js": [
 "/packs/js/server_rendering-eb794d024d4852e8ab55.js"
],
 "js.map": [
 "/packs/js/server_rendering-eb794d024d4852e8ab55.js.map"
 ]
}
 },
"server_rendering.js": "/packs/js/server_rendering-eb794d024d4852e8ab55.js",
"server_rendering.js.map": "/packs/js/server_rendering-eb794d024d4852e8ab55.js.map"
}

...

<%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= stylesheet_pack_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_pack_tag 'application' %>

<link href="https://fonts.googleapis.com/css?family=Open+Sans|Roboto+Slab:700&display=swap" rel="stylesheet">

2019-12-03T15:18:19.023193+00:00 app[web.1]: [aa0374eb-bab1-40cc-b40b-6ae3d195e07d] app/views/layouts/application.html.erb:10

Webpacker.yml

    # Note: You must restart bin/webpack-dev-server for changes to take effect

    default: &default
      source_path: app/javascript
      source_entry_path: packs
      public_root_path: public
      public_output_path: packs
      cache_path: tmp/cache/webpacker
      check_yarn_integrity: false
      webpack_compile_output: false

      # Additional paths webpack should lookup modules
      # ['app/assets', 'engine/foo/app/assets']
      resolved_paths: ['app/assets']

      # Reload manifest.json on all requests so we reload latest compiled packs
      cache_manifest: false

      # Extract and emit a css file
      extract_css: false

      static_assets_extensions:
        - .jpg
        - .jpeg
        - .png
        - .gif
        - .tiff
        - .ico
        - .svg
        - .eot
        - .otf
        - .ttf
        - .woff
        - .woff2

      extensions:
        - .jsx
        - .vue
        - .mjs
        - .js
        - .sass
        - .scss
        - .css
        - .module.sass
        - .module.scss
        - .module.css
        - .png
        - .svg
        - .gif
        - .jpeg
        - .jpg

    development:
      <<: *default
      compile: true

      # Verifies that correct packages and versions are installed by inspecting package.json, yarn.lock, and node_modules
      check_yarn_integrity: true

      # Reference: https://webpack.js.org/configuration/dev-server/
      dev_server:
        https: false
        host: localhost
        port: 3035
        public: localhost:3035
        hmr: false
        # Inline should be set to true if using HMR
        inline: true
        overlay: true
        compress: true
        disable_host_check: true
        use_local_ip: false
        quiet: false
        headers:
          'Access-Control-Allow-Origin': '*'
        watch_options:
          ignored: '**/node_modules/**'

    test:
      <<: *default
      compile: true

      # Compile test packs to a separate directory
      public_output_path: packs-test

    production:
      <<: *default

      # Production depends on precompilation of packs prior to booting for performance.
      compile: true

      # Extract and emit a css file
      extract_css: true

      # Cache manifest.json for performance
      cache_manifest: true

  • Ich würde erwarten, dass Sie festlegen möchten compile: false in der Produktion bedeutet, dass Sie auch laufen sollten rails assets:precompile als Teil des Bereitstellungsprozesses.

    – rossta

    3. Dezember 2019 um 16:35 Uhr


  • Ja, hatte es ursprünglich falsch, wollte es nur ausprobieren, um zu sehen, ob es hilft, aber es hat nichts gebracht. ist nicht rails assets:precompile automatisch mit webpacker ausgeführt? ähnlich wie andere Vermögenswerte?

    – Justin

    3. Dezember 2019 um 16:41 Uhr

  • Gerade aktualisiert zu kompilieren false und rannte rails assets:precompileNo Go 🙁

    – Justin

    3. Dezember 2019 um 16:46 Uhr

1647113108 333 Rails Webpacker 42 findet keine Anwendung in apppublicpacksmanifestjson heroku
rossta

Es sieht so aus, als gäbe es keine application.css in deiner manifest.json was bedeutet, dass Sie möglicherweise kein CSS aus Ihren Webpack-Javascript-Dateien importieren.

Wenn das alles zutrifft, können Sie den Fehler in der Produktion auf eine der folgenden Weisen beheben:

  • Schnelle (vorübergehende) Lösung: Hinzufügen extract_css: false zu deinem production einsperren config/webpacker.yml (was Ihre lokalen Umgebungen nachahmen würde)
  • Wenn Sie CSS nicht mit Webpacker kompilieren möchten: Entfernen Sie <%= stylesheet_pack_tag 'application' %> aus Ihrem Anwendungslayout
  • Wenn Sie CSS mit Webpacker kompilieren möchten: Importieren Sie mindestens eine CSS-Datei aus Ihrem Webpack-Javascript

  • Oh verdammt! sieht so aus, als wäre das das Problem! Herstellung extract_css false, repariert. Ich bin mir nicht sicher, wie ich das übersehen habe, vielen Dank! Das heißt, ich würde es gerne in der Produktion auf true setzen, damit ich das CSS in einer Datei habe, warum sollte Webpacker keine Anwendungs-CSS-Datei generieren?

    – Justin

    3. Dezember 2019 um 18:56 Uhr

  • Wenn Sie kein CSS importieren, gibt es nichts zu exportieren. Ich denke, die ideale Lösung ist zu behalten extract_css: true und entfernen Sie die stylesheet_pack_tag bis Sie bereit sind, CSS mit Webpack zu verarbeiten, fügen Sie dann die stylesheet_pack_tag zurück.

    – rossta

    3. Dezember 2019 um 20:12 Uhr

  • Klingt wie ein separates Problem

    – rossta

    5. Dezember 2019 um 2:56 Uhr

  • Warum wird hinzugefügt extract_css: false nur eine vorübergehende Lösung?

    – t56k

    6. März 2020 um 0:42 Uhr

  • In der Produktion ist es normalerweise vorzuziehen, CSS in eine separate Datei zu extrahieren. Andernfalls sehen Sie möglicherweise einen Flash von nicht formatiertem Inhalt (FOUC), da Sie sich auf Ihr JavaScript verlassen würden, um das CSS einzufügen.

    – rossta

    6. März 2020 um 4:00 Uhr

Wenn Sie Rails 6+ mit Webpacker verwenden, werden aufgrund des neuesten Rails 6-Updates sowohl die Javascript- als auch die CSS-Dateien nach unten verschoben app/javascript anstatt app/assets.

app/javascript:
  ├── packs:
  │   # only webpack entry files here
  │   └── application.js
  └── src:
  │   └── application.css
  └── images:
      └── logo.svg

Wenn Sie jedoch von einer älteren Version auf eine neue Version aktualisiert haben, aber dennoch CSS kompilieren möchten app/assets/stylesheets Ordner und befolgen Sie dann die folgenden Anpassungen:

  1. aktualisieren Sie die unten in config/webpacker.yml für webpack einzuschließen app/assets im gelösten Pfad.
// config/webpacker.yml

resolved_paths: ['app/assets']
  1. Kopieren Sie die untere Zeile nach app/javascript/packs/application.js.
// app/javascript/packs/application.js

import 'stylesheets/application'

Dies sollte Ihr CSS-Kompilierungsproblem beim Ausführen beheben bin/webpack-dev-server.

Ich habe den gleichen Fehler auch auf meiner lokalen Instanz erhalten.

Nachdem ich viele Problemumgehungen ausprobiert hatte, funktionierten die folgenden Schritte für mich

bundle exec rails webpacker:install

Obwohl dieser Befehl mit dem folgenden Fehler fehlgeschlagen ist

gyp: Keine Xcode- oder CLT-Version erkannt! gyp ERR! Konfigurationsfehler gyp ERR! Stack-Fehler: gyp fehlgeschlagen mit Exit-Code: 1 gyp ERR! Stack bei ChildProcess.onCpExit (/Users//Documents/Ruby/udemy/test/alpha-blog/alpha-blog/node_modules/node-gyp/lib/configure.js:345:16) gyp ERR! Stack bei ChildProcess.emit (node:events:376:20) gyp ERR! Stack bei Process.ChildProcess._handle.onexit (node:internal/child_process:284:12) gyp ERR! System Darwin 19.6.0 gyp ERR! Befehl “/usr/local/Cellar/node/15.5.0/bin/node” “/Benutzer//Documents/Ruby/udemy/test/alpha-blog/alpha-blog/node_modules/node-gyp/bin/node-gyp.js” “rebuild” “–verbose” “–libsass_ext=” “–libsass_cflags= ” “–libsass_ldflags=” “–libsass_library=” gyp ERR! cwd /Users/***/Documents/Ruby/udemy/test/alpha-blog/alpha-blog/node_modules/node-sass gyp ERR! node – v v15.5.0 gyp ERR! node-gyp -v v3.8.0 gyp ERR! nicht ok

Um das Problem zu beheben, habe ich die folgende Stapelüberlaufantwort verwendet (unter macOS Catalina)

https://stackoverflow.com/a/60860951/5876113

Dann habe ich den folgenden Befehl ausgeführt

bundle exec rails webpacker:install

Nachdem ich die obigen Schritte ausgeführt hatte, wurde der Fehler nicht erneut angezeigt. Bitte überprüfen Sie, ob dies für Sie funktioniert, da Sie mit dem Problem bei der Heroku-Bereitstellung konfrontiert sind.

  • Die Lösung zum Docker-Build mit Rails und Webpacker. Danke!

    – Andreas Grow

    22. Mai 2021 um 18:56 Uhr

Ich hatte das gleiche Problem nach dem Upgrade von a Schienen Anwendung ab Version Schienen 5 zu Schienen 6.

Ich habe die folgenden Lösungen ausprobiert, aber keine hat bei mir funktioniert:

Webpacker neu installieren

bundle exec rails webpacker:install

Neukompilieren von Assets sowohl lokal als auch in der Produktion

rails assets:precompile

rails assets:precompile RAILS_ENV=production

Meine Knotenmodule und meine öffentlichen/Assets-Dateien löschen und die Garninstallation erneut ausführen:

rm -rf node_modules
rails assets:clobber
rails assets:precompile

Ich habe sogar die kompilierten Produktionsressourcen in Git verschoben und in der Produktion bereitgestellt

rails assets:precompile RAILS_ENV=production
git add public/assets -f
git commit -m "Vendor compiled assets"

Hier ist, was für mich funktioniert hat:

Ich öffnete die config/environments/production.rb Datei und fügte ihr die folgende Konfiguration hinzu:

# Do not fallback to assets pipeline if a precompiled asset is missed.
config.assets.compile = false

Als ich jetzt wieder zu Heroku geschoben habe, hat alles gut funktioniert.

Also, was dieser Befehl tut – ohne diesen Befehl in der Rails 6-Anwendung wird davon ausgegangen, dass config.assets.compile ist eingestellt auf true oder das config.assets.compile standardmäßig auf true. Was also passiert, ist jede Anfrage nach einer Datei in /assets wird an Sprockets weitergegeben. Bei der ersten Anfrage für jedes einzelne Asset wird es kompiliert und in dem Cache gespeichert, den Rails für den Cache verwendet (normalerweise das Dateisystem). Bei nachfolgenden Anfragen erhält Sprockets die Anfrage und muss den Fingerprint-Dateinamen nachschlagen, prüfen, ob die Datei (Bild) oder Dateien (CSS und JS), aus denen das Asset besteht, nicht geändert wurden, und dann, wenn es eine zwischengespeicherte Version gibt, diese bedienen . Diese Einstellung verursacht bekanntermaßen andere Laufzeitinstabilitäten und wird im Allgemeinen nicht empfohlen

Ressourcen: Compile In der Produktion auf True setzen

Das ist alles.

ich hoffe das hilft

Rails Webpacker 42 findet keine Anwendung in apppublicpacksmanifestjson heroku
Arnold Bwaila

Die oben akzeptierte Lösung löst das Problem für die meisten, aber wenn Sie wie ich weiterhin Probleme hatten, nachdem Sie jede Anweisung und jede Lösung befolgt hatten. Das Folgende könnte Ihnen helfen.

Nachdem ich durch ein Kaninchenloch voller Fehler gegangen war, fand ich die folgenden Werke.

Meiner Erfahrung nach hat es mit Webpacker und Ihrer nvm-Installation zu tun. Um die Lösung auszuprobieren, machen Sie zunächst alle anderen Aktionen rückgängig, die Sie zum Debuggen des Problems durchgeführt haben. Sie müssen sicherstellen, dass Sie die neueste Webpacker-Version ausführen.

Ich würde dann ausführen:

    rails webpacker:compile 

in Ihrem Endgerät.

Wenn es ohne Node-Warnung kompiliert wird, ist alles gut. Wenn Sie eine Warnung bezüglich Ihrer Node-Version erhalten oder nicht kompiliert wird, installieren Sie die neueste LTS-Node-Version. meine ist 16.13.1. für Ubuntu. . Das ist wichtig. Die neueste Version von node ist nicht unbedingt die neueste lts-Version. Sie müssen in Ihrem Home-Verzeichnis installieren. Laufen:

    nvm install --lts
    nvm use --lts

Vielleicht möchten Sie dies als Standard festlegen, z. :

    nvm alias default 16.13.1

Stellen Sie außerdem sicher, dass Ihr Anwendungslayout Folgendes enthält:

    <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>

Sobald dies erledigt ist, führen Sie die Webpacker-Kompilierung erneut wie oben aus.

Wenn Sie danach Probleme haben, können Sie auch versuchen, Folgendes in Ihre Datei config / initializer / assets.rb einzufügen:

    Rails.application.config.assets.precompile += %w(application.js)

995000cookie-checkRails: Webpacker 4.2 findet keine Anwendung in /app/public/packs/manifest.json heroku

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy