Fichiers statiques introuvables avec webpack et django

Le problème est que je peux accéder à l’application sur le navigateur, mais pas aux ressources statiques (js, jsx et images).

Technologies que j’utilise:

django-webpack-loader 0.2.4 React 0.14 Django 1.8.5 Python 2.7 

Partie des parameters de Django pour les fichiers statiques:

 103 # Static files (CSS, JavaScript, Images) 104 # https://docs.djangoproject.com/en/1.8/howto/static-files/ 105 106 STATIC_URL = '/static/' 107 STATICFILES_DIRS = ( 108 os.path.join(BASE_DIR, 'assets'), 109 ) 110 111 WEBPACK_LOADER = { 112 'DEFAULT': { 113 'BUNDLE_DIR_NAME': 'bundles/', 114 'STATS_FILE': os.path.join(BASE_DIR, 'webpack-stats.json'), 115 } 116 } 

Le fichier webpack.config.js:

  4 // Dependencies 5 var path = require('path') 6 var webpack = require('webpack') 7 var BundleTracker = require('webpack-bundle-tracker') 8 9 module.exports = { 10 // The base directory (absolute path) for resolving the entry option. 11 context: __dirname, 12 13 entry: './assets/js/index', 14 15 output: { 16 // Where the comstackd bundle to be stored. 17 path: path.resolve('./assets/bundles/'), 18 // Naming convention webpack should use. 19 filename: '[name]-[hash].js' 20 }, 21 22 plugins: [ 23 // Where webpack stores data about bundles. 24 new BundleTracker({filename: './webpack-stats.json'}), 25 // Makes jQuery available in every module. 26 new webpack.ProvidePlugin({ 27 $: 'jquery', 28 jQuery: 'jquery', 29 'window.jQuery': 'jquery' 30 }) 31 ], 32 33 module: { 34 loaders: [ 35 // A regexp that tells webpack user the following loaders on all 36 // .js and .jsx files. 37 {test: /\.jsx?$/, 38 exclude: /ndoe_modules/, 39 loader: 'babel-loader', 40 query: { 41 presets: ['react'] 42 } 43 }, 44 // use ! to chain loaders 45 { test: /\.less$/, loader: 'style-loader!css-loader!less-loader' }, 46 {test: /\.css$/, loader: 'style-loader!css-loader'}, 47 // Inline base64 URLs for <=8k images, direct URLs for the rest. 48 {test: /\.(png|jpg)$/, loader: 'url-loader?limit=8192'} 49 ] 50 }, 51 52 resolve: { 53 // Where webpack looks for modules. 54 modulesDirectories: ['node_modules'], 55 // Extensions used to resolve modules. 56 extensions: ['', '.js', '.jsx'] 57 } 58 } 

Partie de Dockerfile:

  3 COPY start.sh /opt/start.sh 4 5 ADD . /opt/ 6 7 RUN /opt/node_modules/webpack/bin/webpack.js --config /opt/webpack.config.js 8 9 RUN chmod +x /opt/start.sh 

Hiérarchie du projet Django:

 my_project/ ├── Dockerfile ├── api ├── assets ├── my_project ├── db.sqlite3 ├── manage.py ├── node_modules ├── package.json ├── requirements.txt ├── static ├── templates ├── webpack-stats.json └── webpack.config.js 

Il existe deux serveurs exécutant Nginx t01 et t02. t01 est pour proxy et t02 est l’endroit où réside le projet Django. Le serveur proxy semble correct car l’url fonctionne sur le navigateur, seuls les fichiers statiques ne peuvent pas être trouvés (erreurs 404).

Je fais manuellement le paquet de fichiers statiques sur le serveur car il y aura un webpack-stats.json généré qui contiendra les informations de chemin absolu.

Cependant, ce projet s’exécute correctement sur mon ordinateur local.

[MODIFIER]:

J’ai trouvé une solution, juste pour append ceci à my_project/urls.py à la fin de urlpatterns

] + static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)

Dans votre page HTML, avez-vous chargé et rendu le bundle? Cela devrait être dans votre modèle de point d’entrée Django.

 {% load render_bundle from webpack_loader %} {% render_bundle 'app' %} 

Vous avez également besoin de publicPath pour correspondre à vos parameters de fichiers statiques dans Django. Définissez-le dans webpack.config.js:

 output: { path: path.resolve('assets/bundles/'), publicPath: '/static/bundles/', filename: "[name]-[hash].js", }, 

Si vous rencontrez ce problème lors de l’exécution des tests (Django), assurez-vous que le pack Webpack est bien construit:

 ./node_modules/.bin/webpack --watch --progress --config webpack.config.js --colors 

Supprimez ensuite tous les .pyc pour effacer les tests obsolètes.

 find -name "*.pyc" -delete 

Après cela, les tests ne devraient plus se plaindre de l’incapacité de Webpack à trouver le bundle en question.