renative
renative copied to clipboard
Why next.js source maps are in ES5
I would like to have correct crash reports from Sentry lib to show exact place of error in original code. But looks like source maps for web are not showing original code but ES5.
Is it possible to reconfigure maybe settings in next.config.js in order source maps were showing original code?
next.config.js:
const { withRNV } = require('@rnv/engine-rn-next');
const path = require('path');
const fs = require('fs');
const cp = require('child_process');
const config = {
compress: false,
webpack: (cfg, { isServer }) => {
if (!isServer) cfg.resolve.alias['@sentry/node'] = '@sentry/browser';
cfg.module.rules.push({
test: /\.(eot|woff|woff2|ttf|svg|png|jpg|gif)$/,
use: {
loader: 'url-loader',
options: {
limit: 100000,
name: '[name].[ext]',
},
},
});
return cfg;
},
typescript: {
ignoreBuildErrors: true,
},
publicRuntimeConfig: {
deployEnv: process.env.DEPLOY_ENV || 'Development',
customScripts: [],
},
images: {
loader: 'akamai',
path: '',
},
async headers() {
return [
{
source: '/(.*)',
headers: [
{
key: 'X-Application-Version',
value: getPackageVersion(),
},
{
key: 'access-control-allow-origin',
value: '*',
},
],
},
];
},
experimental: {
outputStandalone: true,
},
productionBrowserSourceMaps: true,
};
module.exports = withRNV(config, {
enableNextCss: false,
enableOptimizedImages: true,
});
not sure exactly what prop deals with that but you could do a console.log of the actual config and change whatever you need.
const config = withRNV(config, {
enableNextCss: false,
enableOptimizedImages: true,
});
console.log(config)
module.exports = config
Then run rnv with -i
and maybe --mono
as well, so you see the full debug output.
That way you'll see all the configs and override what you want.
I see that you've added the productionBrowserSourceMaps: true
per Next.js's Source Maps documentation, but since you mentioned Sentry, just wanted to make sure that you followed their Next.js specific Source Maps documentation as well.
Yes I went exactly according Sentry's documentation. There are several approaches to set up Sentry. It always shows bad code, that is in Dev tools Sources of browser. I created also clean next.js project and source code is correct, means original. In our company we recently bootstrapped several new projects with renative and without any Sentry's settings web's source code is wrong.
It looks like source code is twice transpilled. ATM I am investigating if babel is not called in renative twice.
If you look at this source code:
it is using transpilled source from here:
So it looks like app.js?a032 is once more transpilled. And it shouldn't be.
In clean next.js project the source code here is correct:
This is source mapped from here:
I'm new to ReNative, so I probably won't be able to help much with things potentially happening there, but I have recently evaluated the transpilation choices implicitly being made by Next.js. Some things to potentially evaluate:
- tsconfig.json >
compilerOptions.target = 'esnext'
- next.config.js >
config.output.environment
has some goodies to disable - babel.config.js >
presets: [[ 'next/babel', { 'preset-env': { debug: true, targets: { ... }, exclude: [ ... ], include: [] } }]]
Also, have a look at the source for some of the implicit choices for RNV while possibly changing branches/tags to your specific version of Renative:
- tsconfig.json >
"extends": "@flexn/typescript/tsconfig.app.json"
https://github.com/flexn-io/lint/blob/main/packages/typescript/tsconfig.app.json - next.config.js >
const withRNV = withRNVNext
https://github.com/renative-org/renative/blob/main/packages/engine-rn-next/src/adapter.js - babel.config.js >
withRNVBabel
https://github.com/renative-org/renative/blob/main/packages/rnv/src/core/adapter/index.js
- in tsconfig.json we are already using
target = 'esnext'
- I tried also https://github.com/flexn-io/lint/blob/main/packages/typescript/tsconfig.app.json - no success
- I am testing now
*.js
files so typescript settings I think should have no impact on it. -
next.config.js > config.output.environment
nothing related to transpillation source maps. - I was trying your
babel.config.js
change suggestion - nosuccess - I was not able to replace
withRNV
withwithRNVNext
in project I get error
Failed to load next.config.js, see more info here https://nextjs.org/docs/messages/next-config-error TypeError: withRNVNext is not a function
- we are already using
withRNVBabel
inbabel.config.js
in tsconfig.json we are already using target = 'esnext'
I too found that this didn't change much. Worth noting that I was making changes and evaluating the size of the resulting bundle to determine if less things were being transpiled. None of that research was related to source maps specifically.
I tried also https://github.com/flexn-io/lint/blob/main/packages/typescript/tsconfig.app.json - no success
I found that this was essentially the default extends
with the starter project at least. Since there are implicit choices in there, attempting to overcome them might warrant additional evaluation.
I was trying your babel.config.js change suggestion - nosuccess
This is where I was able to alter the implicit transpilation choices a bit more and reduce the amount of things being transpiled. One of the larger shifts was targets
and targetting more recent browsers, though it is worth noting that there is a browserslist
declaration in package.json which may have some influence. There is a lot to unpack here: https://babeljs.io/docs/en/babel-preset-env
I was not able to replace withRNV with withRNVNext in project I get error
More was just noting that although the linked source exports withRNVNext
, it is re-exported as withRNV
and what was in use with the default babel.config.js starter project at least.
we are already using withRNVBabel in babel.config.js
Right right, might want to have a look at the linked source to understand what choices it is making including any other choices from things upstream from there too.
Did you reproduced this issue in your side?
Nopers, I have not. Will let you know if/when I go down the path of reproduction. I can confirm there are no source maps available by default with the starter project.
I created new renative project based on renative-template-hello-world
template with no code changes.
It is not even needed to turn on source maps when you run project in debug mode (npx rnv run -p web
). They are there by default. It is cuased by default next option devtool: eval-source-map
of webpack.
And issue is also there:
//next.config.js
const { withRNV } = require('@rnv/engine-rn-next');
const path = require('path');
const config = {
projectRoot: path.resolve(__dirname),
};
module.exports = withRNV(config);
// babel.config.js
const { withRNVBabel } = require('rnv');
module.exports = withRNVBabel({});
// package.json
{
"name": "testprojekt",
"version": "0.1.0",
"dependencies": {
"renative": "0.35.4",
"react-native-web-image-loader": "0.0.5",
"react-native-gesture-handler": "1.4.1",
"react-native-reanimated": "1.13.3",
"react-native-vector-icons": "8.1.0",
"@reach/router": "1.3.4",
"hash-source": "1.0.4",
"@react-navigation/core": "5.12.3",
"@react-navigation/drawer": "5.9.0",
"@react-navigation/bottom-tabs": "5.1.1",
"@react-navigation/material-bottom-tabs": "5.1.1",
"@react-navigation/native": "5.7.3",
"@react-navigation/stack": "5.9.0",
"@react-navigation/routers": "5.1.0",
"@react-navigation/material-top-tabs": "5.1.1",
"@react-navigation/web": "1.0.0-alpha.9",
"@react-native-community/masked-view": "0.1.6",
"react-native-safe-area-context": "3.1.0",
"@react-native-community/viewpager": "2.0.2",
"@noriginmedia/react-spatial-navigation": "2.12.1",
"react-native-safe-area-view": "0.14.5",
"react-native-screens": "2.2.0",
"react-native-tab-view": "2.13.0",
"react-native-google-cast": "github:hosek/react-native-google-cast#sdk4.4.5",
"react": "17.0.2",
"react-art": "17.0.2",
"react-dom": "17.0.2",
"react-native": "0.63.4",
"react-native-web": "0.17.5",
"next": "12.0.9"
},
"devDependencies": {
"rnv": "0.35.4",
"renative-template-hello-world": "0.35.4",
"@rnv/engine-rn-next": "0.35.4"
}
}
Could it be considered as a bug?
this is no longer the issue in 1.0.0-rc.18.