-
Notifications
You must be signed in to change notification settings - Fork 70
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
JS Toolkit Angular Adapt index.js directory reference in .jar incorrect in automated build #613
Comments
Hey @wwkrem, thanks for so much detailed bug report :-). There's a problem with this: we already changed that long ago from the |
Unfortunately, we have the same behavior here, when the project directory does not match the name of the Angular Portlet. e.g. when the root directory of the portlet is c:\projects\myproject and the portlet has the name my-portlet then the require in adapt-rt.js is: const polyfills = require("./myproject/polyfills.js"); But the directory in the jar is /my-portlet, so after deployment, the portlet will not work. Expected behavior that the require in adapt-rt.js is: const polyfills = require("./my-portlet/polyfills.js"); @izaera : Is there any chance that this will be fixed in the near future? Update: After investigating the liferay-builder libraries, currently, the project root directory is used by Liferay. For me, this seems to be more wrong to me, than the previous behavior which used the package.json name. In fact, Angular uses the project name of the app defined in the angular.json file. Reverting to the package.json or using the "defaultProject" in angular.json would be more usable in scenarios a build server is used for building the portlet. In addition, a possibility to overwrite the default behavior e.g. in the .npmbundlerrc file would be great. |
@ChrisMayor In case you are looking for a temporary solution. We chose to use a gulp task to replace the file during the build:
We call the task in an npm script and only use it when building with Jenkins, right before we do a npm clean-build script. Not what we were hoping for, but it works for now. |
@wwkrem Thank you for the gulp task. We are using it in our Azure Devops Pipeline and it works great |
Hey there π I hope to revisit adaptations in the short term, now that we have decided what to support and what not to support for Vue so I will include this too and any other fixable bug regarding adaptations. I will create a document with supported versions and specs too, so that we can put some order in this "adaptation mess". The problem with adaptations is that it is a bit of a magic process because we need to process the final output of other tools (not the source) which makes the whole process prone to instability as things may change through time (or because of configuration changes) without nobody noticing it until it fails. |
@wwkrem I noticed that a third replacement - at least when you use a global stylesheet - is necessary. package.json, if you use this, then the reference to the stylesheet gets corrupted:
This is the final version of the task:
|
@izaera Thank you for revisiting. You guys are doing great work. I can imagine it is quite complex to develop and maintain all these adaptations. @ChrisMayor We never needed this css workaround. Perhaps because we package it when building Angular and the reference of these styles in the angular.json build params. I am not sure though. Great to hear you found a workaround. |
Hey guys π , while we see what's going on with yeoman adapter generator, can you try what I suggest here π #850 (comment) and report your experience? The liferay-cli based adapter should be much more stable and, in any case, it's better to fix anything there than in yeoman unless it is absolutely needed. Thanks π |
I assume this is already fixed, since nobody replied since long ago. |
Issue type (mark with
x
)Version (mark with
x
)Description
The JS Toolkit Adapt for Angular uses the liferay-npm-build-support code to generate a portlet in .jar format.
It uses liferay-frontend-projects/maintenance/projects/js-toolkit/packages/liferay-npm-build-support/src/resources/build/angular-cli/index.js.ejs to generate the index.js file in the .jar of the portlet.
The index.js fetches the main Angular files polyfilles, runtime and main. To do this, liferay-npm-build-support uses:
This works great when building a portlet locally, however, the reference to the basename of the directory causes issues in an automated build, like a Jenkins build. It uses the Jenkins workspace directory to create this reference, which is not the same as the folder structure in the jar.
For example:
In the .jar the folder that contains the polyfills, runtime and main is:
\iv-example-angular-adapt-portlet-0.0.2-SNAPSHOT.jar\META-INF\resources\iv-example-angular-adapt-portlet\
However, the references in the index.js contain the workspace directory name from Jenkins:
// Require webpack bundles generated by Angular CLI build.
const polyfills = require("./le-angular-adapt-portlet_develop/polyfills");
const runtime = require("./le-angular-adapt-portlet_develop/runtime");
const main = require("./le-angular-adapt-portlet_develop/main");
Hence, the portlet will never start or run and is defective due to the faulty reference in the index.js.
To make it possible to automatically build portlets correctly, changing the require to project.name might fix this.
The text was updated successfully, but these errors were encountered: