Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Source maps + publicPath #1290

Open
SamyPesse opened this issue May 15, 2021 · 4 comments
Open

Source maps + publicPath #1290

SamyPesse opened this issue May 15, 2021 · 4 comments

Comments

@SamyPesse
Copy link
Contributor

When bundling a node.js app which is referencing some assets that are also used on the client side (ex: sir), we use publicPath to ensure the same absolute urls are referenced everywhere.

The issue is when using this option in combinaison of sourcemap: true, the reference to the source map file in the JS code is then an absolute url prefixed by publicPath.

Prefixing the sourceMappingURL with the publicPath makes sense for a browser application, but prevent the combinaison of publicPath + sourceMap for node apps.

It'd be great if there was an optional sourceMapPublicPath url to override this where the option passed could be sourceMapPublicPath: ./ to indicate to use a relative file path in sourceMappingURL.

@evanw
Copy link
Owner

evanw commented May 15, 2021

It sounds to me like you need to build your app twice, once for the client and once for node, and use a different publicPath for each. Building the code base all at once for both the client and node sounds like it would introduce other issues such as not being able to use the correct platform setting. If you still think what you are doing is the right approach, could you provide an example with more information about the client/node duality so I could better understand what you mean?

@SamyPesse
Copy link
Contributor Author

We are building the app twice, one esbuild build for the node server and one esbuild build for the browser code. But we are sharing some options between both (publicPath is one of the shared option).

An example is something like:

import * as React from 'react';
import imageSrc from './image.png';

function MyApp() {
  return <img src={imageSrc} />
}

If you want to do server and client rendering for this component, you expect imageSrc to be the same url in both builds. Using publicPath and other common options such as assetNames make it easy.
The browser build will work well because prepending the sourceMappingURL with publicPath makes sense, but it breaks the lookup of the source maps for the node build.

Unrelated to this specific example, it's currently not obvious that the publicPath option impacts the sourceMappingURL, it's probably worth being documented in the sourceMap option.
I personally think considering source maps as relatives to the JS bundle is a better default solution.

@DmitryAnansky
Copy link

Hi, also have related question about resolving absolute, not relative path for similar case.

import * as React from 'react';
import imageSrc from './image.png';

function MyApp() {
  return <img src={imageSrc} />
}

When I am using
assetNames: path.join('static', '[name]-[hash]') option
I am getting returned src as relative path to my public folder,
<img src="./static/image-WVUTZNEB.png" alt="cant find image">
witch prevent .png from loading in nested routes.

Is there the way to configure it as absolute path, to get
<img src="/static/image-WVUTZNEB.png" alt="cant find image"> instead ?
Thank you

@VitorLuizC
Copy link

I have same issue, an option or way to ensure absolute path from '/' instead of relative from source to the asset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants