izaera
commented
3 years ago 1) Yes, I think we can make liferay-7.4-GA1 on liferay-npm-bundler and that should do it... We can leave the semver expression open so that if the user wants to force a newer version of the bundler he can.
2) Well, hopefully that doesn't happen and we only need 1.x versions... However, the version in the name is necessary, because if we code it inside the real version number (i.e. if we name the dependency liferay and use 7.4.1 as version number, we lose the possibility to release more versions in case anything goes wrong (because we have used the three numbers available). Also, we don't have any control over Liferay versioning scheme so, if it varies in the future we are in trouble. Even now we could be, because there's DXP in addition to CE.
A lateral thinking approach solution to having a version 7.2.1 for liferay-7.4-GA1 would be to simply skip 7.x versions, to avoid confussion :sweat_smile: . So we jump from 6.x to 8.x, for example. Or something similar...
3) :thinking: It probably makes more sense as a normal dep, since you are saying you are relying on Liferay 7.4 platform for your project to work and that's clearly a normal dep. But, on the other hand, that would make anyone depending on your project download the whole JS Toolkit and deps even if they didn't use them. TBH, I'm not sure about the implications of that...
- Does it make that someone depends on one of these projects?
- If it makes, can we assume that any dependent project will need to be built with the bundler and the platform? Sounds like it should, but I haven't analyzed it...
I think we should think about this in depth, because it looks like it's an important aspect of the model we are defining.
4) Yes it is, but we can modify the bundler so that liferay-7.4-GA1 does something to make the bundler infer it.
5) Those are needed for two utility scripts in liferay-npm-build-support: translate and deploy. The translate one is used to invoke Microsoft Translation Services to maintain language keys and it is inside the JS Toolkit only because we put it there long ago, but it could be extracted, since it's self contained. Regarding deploy, we need it to copy the generated JAR to the Liferay deploy dir, but could be as well be done from outside the JS Toolkit.
In general you may think of liferay-npm-build-support as something similar to npm-scripts but living inside the JS Toolkit workspace for historical reasons.
6) I like embedding the script in the liferay-7.4-GA1 dependency for now. It looks simple and flexible, as you say. We always have time to make a new project in the future if needed.
So I'm going to work in a PR to try to include these things in the frontend-projects repo. That way we can start polishing this based on that PR.
javiergamarra
bryceosterhaus
I wasn't sure the best way to provide feedback and thought maybe an issue was best... Anyways, I think this is a really good direction and is giving me hope for this fat jar idea. I had a few notes and thoughts on the implementation but overall I think it's looking pretty good.
Would it be possible to merge dependencies and the bundler script could be called from that other package?
Naming and version I'm not totally opposed to your current naming scheme, but my one concern would be that we might be telling someone "You need liferay-7.3-GA2 at version 7.2.0". which might be confusing for people.
Specify as a normal dependency Since we are including dependencies that will end up on the client, can we call this a normal dependency rather than dev? I would be worried that developers might see "devDependency" and feel like they have a dependency-less project when they really don't.
Is the preset necessary? https://github.com/izaera/fat-jar-sample/blob/0c952e9a780312c5acf51610ca9967f847901458/packages/fat-test/.npmbundlerrc#L1-L3
Can we infer the preset based on what dependency and version they specify in their package.json? This specification seems slightly redundant. Or is there a use case where we might have a dependency of
liferay-7.4-GA1and a preset of some other version?I'm guessing this is boilerplate we already require but where does this come from again and why is it necessary?
One thought I had while reading through your commits was to create a light wrapper included with our main dependency(
liferay-7.4). Calling this in build and deploy would determine whether bundler is used, if babel is used directly, if lnbs is used, etc. I may be oversimplifying some of this here but we may be able to hide some of our tooling. This would also allow us to have a little more flexibility with our bundler and not have to pack it with too many specifics for this fat jar use case.