search

liferay / liferay-frontend-projects

A monorepo containing assorted Frontend Infrastructure Team projects
Other
69 stars 69 forks source link

Unable to debug React JS widget with code not minified #1096

Closed luizfmarins closed 1 year ago

luizfmarins commented 1 year ago

Issue type (mark with x)

Version (mark with x)

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):

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

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

izaera commented 1 year ago

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.

izaera commented 1 year ago

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

image

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.

izaera commented 1 year ago

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...

izaera commented 1 year ago

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... :-/

izaera commented 1 year ago

Apparently the first babel phase is not generating source maps.

luizfmarins commented 1 year ago

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.

izaera commented 1 year ago

Yeah, I think this was broken with @liferay/cli for some reason...

izaera commented 1 year ago

I think this fixes it.

izaera commented 1 year ago

This release https://github.com/liferay/liferay-frontend-projects/releases/tag/portal-base%2Fv1.6.1 should fix the problem.

luizfmarins commented 1 year ago

Hi Ivan,

I tested it and it works now. image Thank you very much.

izaera commented 1 year ago

clap