What is recommended setup for developing 7.0/7.1, and 7.2 themes on the same machine??

[LucyI]

I need to continually develop 7.0, 7.1, and 7.2 themes. From the docs it sounds as if generator-liferay-theme v8 and liferay-theme-tasks v8 are needed for 7.0 and 7.1, whereas v9 of both are needed for 7.2.

Is this correct? And if so, since generator-liferay-theme is a global install, how is it possible to install both v8 and v9 on the same machine (Win 10)?

If both versions of the generator are installed, how does yeoman know which version to use when calling yo liferay-theme?

Lastly, some clarification of dependency compatibility would be great: specifically which versions of node, npm, gulp and node-sass are compatible with both v8 AND v9 of generator-liferay-theme and liferay-theme-tasks? I have discovered the hard way that the latest versions of node and gulp are not compatible...

Thanks, and would be great of this info could make its way into the docs.

[wincent]

generator-liferay-theme v8 and liferay-theme-tasks v8 are needed for 7.0 and 7.1, whereas v9 of both are needed for 7.2.

That's correct. And in a little more detail, the Compatibility table in this repo's README summarizes exactly what you can do with v8 and v9.

I'd say the answer to your other questions depends on how often you need to switch between working on 7.0/7.1 themes and 7.2+ themes. There are tools available to manage multiple, isolated installations of Node and global packages; some examples:

• nvm (Node Version Manager, which apparently may work on Windows in the Windows Subsystem for Linux layer, or you could try nvm-windows or nodist).
• n (again, not directly supported on Windows but seems to work in WSL).
• nodenv (again seems to target WSL) or one of half a dozen or so alternatives listed on its wiki.
• have (again, will need some kind of Bash compatibility layer via WSL).

There are also heavier-weight solutions involving Vagrant or Docker (example tutorial; Windows-specific docs here).

Personally, however, I just install the version I need whenever I need to switch (npm install -g generator-liferay-theme@8.x will give me the latest v8 version) because it allows me to sidestep the complexity of installing and managing any of the tools listed above, takes about a minute, and gives me a robust result where I know for sure exactly which versions I have installed and will be used.

how does yeoman know which version to use when calling yo liferay-theme?

I believe it uses the first-found available version. In theory, however, it should be possible to try to trick it into temporarily running a specific version with npx, although I haven't tested it. The idea, though, would be to install the latest v9 packages globally for convenience and use them normally, but then when you need to run 8.x you would do it with npx:

npx --ignore-existing -p yo -p generator-liferay-theme@8.x liferay-theme-tasks@8.x -c 'yo liferay-theme'

some clarification of dependency compatibility would be great: specifically which versions of node, npm, gulp and node-sass are compatible with both v8 AND v9

I'm not a technical writer, but my recommendation here to avoid going insane would be to always try and use the version of NodeJS that (your targeted version of) liferay-portal itself uses. Last time I checked in my local environment, that was v10.15.1. I usually use yarn, but if I must use npm, I always use whatever version of npm comes with node. In terms of gulp, we currently depend on the latest 3.x release (moving to v4 would be a big breaking API change).

I am skeptical about documenting specific versions though because such documention could all too easily get out of sync. At the end of the day, the source of truth about version dependencies is the package.json files. In both v8 and v9, as of today, if you look at the versions you get when you do an install, they are gulp v3.9.1 and node-sass v4.11.0 for both.

I have discovered the hard way that the latest versions of node and gulp are not compatible...

I'm not sure which specific issue you're pointing to here, but it is sadly true that node-sass in particular is a source of headaches here because it provides bindings to the libsass C library which are totally dependent on specific versions of NodeJS (see their compat table). This is one of the reasons why I recommended above to "use the version of NodeJS that ... liferay-portal itself uses", to avoid the pain of accidentally introducing a discrepant version of node-sass. (Aside: we'd like to migrate away from node-sass precisely because of these kind of headaches, but it may be quite a large undertaking to do so.)

[LucyI]

Thank you for this incredibly detailed, informative response. Going forward I will need both versions nearly daily -- so will probably have a look at multiple installations and then give up when it starts to feel overwhelmingly complicated. ;)

Your method sounds like more my speed. If I decide to install each version as needed, would I have to uninstall the currently installed version first? Or does it all get overwritten with each install?

Wish list: Separate generators with distinct names (theme-generator-8 and theme-generator-9 for instance) so that both can be installed on same machine. Or, reconfigure the theme generator to be installed inside each theme's root folder along with the theme tasks? I have no idea what would be involved in this so please ignore me if this is a preposterous suggestion.

[wincent]

If I decide to install each version as needed, would I have to uninstall the currently installed version first? Or does it all get overwritten with each install?

My understanding (based on what I see when I look at the output of npm list -g) is that you can only have a single version of a global dependency at any one time. So if you install generator-liferay-theme@8.x, it will replace any previously existing globally installed version. If you then run npm install -g generator-liferay-theme, the latest (ie. v9) will replace the v8 version. And if you look at the dependency tree using npm list -g, you will see that v8 of the generator brings along with it v8 of liferay-theme-tasks, and v9 of the generator brings along wiht it v9 of the tasks: you'll only have one installed at a time.

For example, after installing v9, npm list -g -depth 1 shows:

/Users/glh/n/lib
├─┬ generator-liferay-theme@9.4.0
│ ├── async@1.5.2
│ ├── chalk@2.4.2
│ ├── inquirer@0.12.0
│ ├── insight@0.10.3
│ ├── liferay-theme-tasks@9.4.0
│ ├── lodash@4.17.15
│ ├── minimist@1.2.0
│ ├── yeoman-generator@3.2.0
│ └── yosay@0.3.0

If I then install v8, it shows:

/Users/glh/n/lib
├─┬ generator-liferay-theme@8.1.1
│ ├── async@1.5.2
│ ├── chalk@2.4.2
│ ├── inquirer@0.12.0
│ ├── insight@0.10.3
│ ├── liferay-theme-tasks@8.1.1
│ ├── lodash@4.17.15
│ ├── minimist@1.2.0
│ ├── yeoman-generator@3.2.0
│ └── yosay@0.3.0

Separate generators with distinct names (theme-generator-8 and theme-generator-9 for instance) so that both can be installed on same machine.

That's certainly an interesting idea. Sounds like it could work fairly well.

[jbalsas]

Hey @LucyI, there's something here I'm not sure I quite understand...

When you say you need to work with the different versions... are you continuously creating themes alternating versions? That sounds like an unlikely scenario...

The liferay-theme-tasks are installed locally to the theme, so you shouldn't need to install them globally. The only thing that needs to be installed globally is the generator, which you should only need to create new or update existing themes.

I think the best approach for running different generators consistently would be the npx approach that @wincent already shared.

[LucyI]

Hi @jbalsas As a front-end developer with multiple clients, each with their own schedule for when (if ever) they will upgrade their portal -- working on different versions of LR at the same time does not seem at all unlikely to me. At any rate, it is my current situation and I don't see it changing in the near future. I'm just thankful none of my clients are on LR 6... ;)

I do often create new themes, either for a client or for myself to test new ideas. I ended up setting up an Amazon Workspace and do all the 7.2 development there for now. Not free, but considerably easier than struggling with new and finicky tools.

[jbalsas]

Hi @LucyI, thanks a lot for those insights!

We're just looking to understand your use case and workflow to better support it. Our more common case (as far as I could tell) is one-offs of theme creation or updates, so I don't think we were fully considering your case.

If possible... could you share a bit more of your workflow without disclosing sensible information? How often do you create/update themes? Is it once a week? Once a month? I already assume, based on what you mention that you touch the whole 6.2.x - 7.2.x range at the same time?

/cc @david-truong, @gamerson, can you take note of this so we can include this feedback into our frontend Workspace improvements in the future?

[jbalsas]

@LucyI, another question, is it correct to assume that you use the themes-toolkit directly from node and not through other Liferay apps such Liferay Workspace?

[LucyI]

Thanks so much for asking for my feedback. I hope others will comment with their experiences as well, since I don't know if my workflow is typical.

Yes, I do use the themes-toolkit directly. And really appreciate that setup since I can use the tools that are familiar to me. (Or should I say, I am familiar to the tools, since I think VS Code knows me better than I know myself.)

In my experience there is really no such thing as one-off theme creation. In my process, custom theme design is inherently tied to the content planning process. Usually the first iteration of a custom theme can take anywhere from 6 months to a year depending on complexity of the project and the client's own timeline and workflow. But websites also grow over time, improvements are made, new functions are added -- and therefore themes also change to accommodate the new content and requirements. So a theme design is never really "done".

I do have some 6.x.x themes hanging around on my system, as that is where I started my Liferay journey, but those original projects have since upgraded to LR 7. So now my theme design work is for 7.0, 7.1 and 7.2.

Most of my clients have stayed with whatever version of 7 they first installed and don't have plans to update in the near future. I have one project that is planning to update from 7.0 to 7.2 -- work on their 7.0 theme is continuing alongside the development of their 7.2 theme.

I work on existing themes almost daily, and create new themes several times a month, depending on where I am in the lifecycle of a project. And as I mentioned I also like to make new themes for my own tests, to try out a particular function or just to familiarize myself with each new version. In particular there is a lot to learn about the new templates and styles in 7.2.

Throughout the life of a theme it is common for there to be several version updates to the toolkit, and often I have experienced issues with upgrading a theme's liferay-theme-tasks version, or for it to get out of sync with the installed version of the generator, or some other dependency issue.

I hope this is helpful, and please let me know if you have other questions. :)

[david-truong]

@LucyI one suggestion I have is to not use the global installation and create your own aliases. With our java cli, we install yo and the generators into a folder and call yo manually. This allows us to give each yo installation it's own set of generators.

[wincent]

We've just migrated this project to the liferay-frontend-projects monorepo in the name of consolidation. As this issue is quite old now, I'm not going to transfer it automatically. If you consider it to be still relevant, please create a fresh issue over in the new repo.