Using baseUrl for react-router & code splitting

[MrCrimp]

Continuation of #425
First, great call to make baseUrl part of the default parameters.

For the react-redux template, to make use of baseUrl it's necessary to modify boot-client.ts a bit, you'll probably want

// instruct the router to ignore that part when resolving routes so they can be defined without taking baseUrl into account
const history = useRouterHistory(createHistory)({
     basename: baseUrl
   });

Those <LinkTo/> components should then work as expected

---

Now, for the webpack and public path when using code splitting.

The scenario is that you do e.g

function loadLocale(){
  require.ensure([], (require) => {
      const request: any = require( 'bundle-loader?lazy!react-intl/locale-data/' + locale );
     //.....

Given that webpack public path now is absolute path /dist/ and in your code you do a
call to loadLocale() then webpack will issue a request to
yourserver.com/dist/1.js no matter what, when what you really wanted was yourserver.com/vdir/dist/1.js

So I think it's necessary to prepend the newly introduced baseUrl when setting webpack.public path in aspnet-webpack code, instead of forcing it to absolute e.g /dist/

[SteveSandersonMS]

Thanks for the info about this.

So I think it's necessary to prepend the newly introduced baseUrl when setting webpack.public path in aspnet-webpack code

Which bit of aspnet-webpack sets Webpack's publicPath? Are you talking about the LoadViaWebpack code? If so, that's currently being deprecated in favour of building a Node-compatible prerendering bundle at build time. It ensures that server-side and client-side execution paths will be consistent.

I don't see how this is something that could possibly be handled automatically, because the PathBase information doesn't exist until runtime (and in fact, not even outside the context of a specific HTTP request). So we can't put it into your built files. It will be necessary to configure your base URL manually inside webpack.config.js, as far as I can see.

I've filed a separate issue about trying to make HMR work from non-root URLs in development: #488

Let me know what you think. Can we close this in favour of #488?

[MrCrimp]

Which bit of aspnet-webpack sets Webpack's publicPath? Are you talking about the LoadViaWebpack code?

Yes, I was probably refering to that part of the code that uses a .Net Path class that requires the publicPath to begin with '/'.
When deployed, if publicPath was allowed to be relative, e.g 'dist/' then the request issued by the code splitting (in production) would be correct.

If that part of the code is now deprecated, and by using the new webpack built server bundle, we would be allowed to use a relative publicPath in our webpack.config.js, without an error being thrown by aspnet-webpack, right?
If so, then you can go ahead and close this in favor of #488 :)

[SteveSandersonMS]

I don't know how a relative publicPath would make sense in Webpack.config.js, since at compile time, it has no idea what the path would be relative to (it doesn't know where you're going to deploy things, or what URL people are going to be on when they load the bundles in their browser). But if somehow that works for you that's great.

I will close this in favour of #488, but please let me know if you think there's anything else missing.

[MrCrimp]

The reason for having a relative public path is is that webpack internally prefixes request url's to codesplit bundles with its runtime global '__webpack_public_path__' https://webpack.js.org/configuration/output/#output-publicpath This is the reason for the previously mensioned hack where I remove the leading slash.  Say you build your product once and deploy the same build to both root and non-root IIS sites like we do, then it's not a preferred option to build with different webpack configs for each deployment.  I hope that explained it.  On Mon, Dec 5, 2016 at 6:02 PM +0100, "Steve Sanderson" <notifications@github.com> wrote: I don't know how a relative publicPath would make sense in Webpack.config.js, since at compile time, it has no idea what the path would be relative to (it doesn't know where you're going to deploy things, or what URL people are going to be on when they load the bundles in their browser). But if somehow that works for you that's great. I will close this in favour of #488, but please let me know if you think there's anything else missing. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.