React-loadable gets chunks only from relative path
Asked Answered
F

1

6

I'm using webpack 4.6.0 and babel 7.0.0 to build react 16.3 web app.

My js assets are under https: //domain/js/app.bundle.js

I use react-loadable to split components into chunks. The chunks are also located under /js/, however, react fetches them from the relative path, that is:

https: //domain/1.app.bundle.js

which of course doesn't work.

Question: How do I tell react or webpack to use the absolute path /js/ for fetching chunks?

Here is my webpack.config.json

var path = require('path');

module.exports = {
    mode: 'production',
    devtool: 'eval-source-map',
    entry: './js/src/app.js',
    watch: false,
    watchOptions: {
        aggregateTimeout: 300,
        poll: 1000,
        ignored: /node_modules/
    },
    output: {
        path: path.resolve(__dirname, "output/js"),
        filename: 'app.bundle.js',
        chunkFilename: '[name].app.bundle.js',
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                loader: 'babel-loader',
                include: path.resolve(__dirname, "js/src"),
                query: {
                    presets: ['@babel/preset-react'],//, 'es2015'],
                    plugins: [
                        'transform-class-properties',
                        '@babel/plugin-syntax-dynamic-import'
                    ]
                }
            },
            {
                test: /\.scss$/,
                include: path.resolve(__dirname, "sass"),
                loaders: ['style', 'css', 'sass']
            }
        ]
    }
};

And here are the packages i have in package.json

    "@babel/plugin-syntax-dynamic-import": "^7.0.0",
    "@material-ui/core": "^3.0.3",
    "@material-ui/icons": "^3.0.1",
    "@babel/cli": "^7.0.0",
    "@babel/core": "^7.0.1",
    "babel-loader": "^8.0.2",
    "babel-plugin-transform-class-properties": "^6.24.1",
    "babel-preset-es2015": "^6.9.0",
    "@babel/preset-react": "^7.0.0",
    "node-sass": "^4.9.2",
    "react": "^16.3.2",
    "react-addons-css-transition-group": "^15.6.2",
    "react-dom": "^16.3.2",
    "react-loadable": "^5.5.0",
    "react-swipeable-views": "^0.12.13",
    "react-tap-event-plugin": "^3.0.3",
    "scss-compile": "^0.1.7",
    "webpack": "^4.6.0",
    "webpack-cli": "^2.1.2",

And here is the react code that I changed to test the code splitting

import React from 'react';
import Loadable from 'react-loadable';

const PV = Loadable({
    loader: () => import('./PV/PV'),
    loading: () => <div>Loading...</div>,
});
Foison answered 14/9, 2018 at 9:38 Comment(0)
F
7

Solved

output: {
    path: path.resolve(__dirname, "output/js"),
    filename: 'app.bundle.js',
    chunkFilename: '[name].app.bundle.js',
    publicPath: '/js/'  <------------------ this was the missing piece.
},
Foison answered 14/9, 2018 at 10:36 Comment(4)
now that publicPath is set to '/js/' , wouldn't all your other static assets (images/fonts) start failing as webpack would now try to resolve them based on this path?Ketubim
@Ketubim I can't answer you. In this project webpack doesn't output anything other than the javascript bundle. However, you're talking about another section, the dev-server, which has the property contentBase that is equivalent to document root in apache. that is where your public assets and index.html resides. PublicPath is where js bundle resides as far as I understand.Foison
As much as I understand, contentBase is used in dev server to change where the dev server might look for static files and chunks apart from memory. publicPath on the other hand is like saying that all the relative imports in your app would be prefixed with '/js/' in the generated bundle. So if by default webpack was to look for files in the build directory, now it would look for those in public/js directory, which is why I suggested that all your relative urls might now be resolved from /js/ . Thanks for the response though. Really appreciate it.Ketubim
True, I do use /js as prefix, haven't thought of the relationship since it worked. Thanks for explainingFoison

© 2022 - 2024 — McMap. All rights reserved.