Unable to debug React JS widget with code not minified

Question

Unable to debug React JS widget with code not minified

luizfmarins opened this issue 2 years ago · 11 comments

luizfmarins commented 2 years ago

Issue type (mark with `x`)

🤔 Question
🐛 Bug report
🎁 Feature request
🤷‍♀️ Other

Version (mark with `x`)

2️⃣ v2.x
3️⃣ v3.x
Not sure which vesion.
I'm using com.liferay.gradle.plugins.workspace 4.0.24 to build it.

Description

Desired behavior:
During development, I should be able to deploy a React JS widget on Chrome using the non minified code.

Current behavior:
I can debug using only the minified code

Repro instructions (if applicable):

Create a new react widget using liferay new try-debug
Setting NODE_ENV to development: export NODE_ENV=development
Using portal-developer.properties: include-and-override=portal-developer.properties
Deploy the widget to a Liferay 7.4 U54. Add to the page.
Result:

Other information (environment, versions etc):
Liferay 7.4 U54
com.liferay.gradle.plugins.workspace = 4.0.24
Sample project: try-debug-fe.tar.gz
Slack thread: https://liferay.slack.com/archives/C03CAD9EF/p1677710229122429?thread_ts=1656002160.024079&cid=C03CAD9EF
Support ticket: https://liferay-support.zendesk.com/agent/tickets/82508

Answer 1 · 2023-03-03T10:14:45.000Z

Mmm, don't know why, I thought this was related to a custom element CE, but it's not, of course. It's an AMD portlet. Source maps should work for custom element CEs.

Now, regarding AMD portlets, IINM, full-blown source maps have never been supported for this type of project...

Specifically, source maps will always be problematic in any AMD build because we wrap code built with a previous tool (babel, typescript, ...), that has already generated a source map, with Liferay.Loader.define, which "breaks" the source map unless we rewrite it.

Additionally, modifying a source map after it's generated is quite difficult so I think we never implemented it, but I wouldn't swear for it. I need to check in depth the source code, because I don't remember.

Can you confirm if you have seen this working before? 🤔 Thanks.

The reason why I'm doubt is because adding a single line, like Liferay.Loader.define may make rewriting the source map feasible since it is a simple offset from the original one, thus I'm not sure if we did that in the past or not, finally. I will check the source code of npm-bundler, but having a confirmation would be quite useful.

Answer 2 · 2023-03-03T11:51:41.000Z

According to liferay-npm-bundler report file, this is all we run when transforming a .js file:

I can't see any place where we tweak the source maps generated by Babel, which makes me suspect this has never worked as requested...

I'm going to check each phase internally.

Answer 3 · 2023-03-03T12:00:13.000Z

However, if the wrap-modules-amd is done by a babel plugin, I think it should work as long as we load the source map generated by the previous babel/tsc invocation and pass it to the liferay-npm-bundler phase, which I think we did some time in the past...

Answer 4 · 2023-03-03T12:02:32.000Z

Yep, this is what should make the magic happen -> https://github.com/liferay/liferay-frontend-projects/blob/master/maintenance/projects/js-toolkit/packages/liferay-npm-bundler/src/steps/transform.js#L210

Now we only need to know why it doesn't... :-/

Answer 5 · 2023-03-03T12:31:06.000Z

Apparently the first babel phase is not generating source maps.

Answer 6 · 2023-03-03T14:38:57.000Z

Hi Ivan,

Can you confirm if you have seen this working before?

This is the first project I'm using @liferay/cli.
In my previous projects with Liferay 7.1 and 7.2 it used to work, but we were using the liferay-npm-bundler.