Migrating a project to SAP Web IDE Full-Stack
In this recent blog post, we announced that SAP Web IDE Full-Stack is ready for SAP Fiori developers and suggested you to start migrating your projects from SAP Web IDE.
Migrating to the new SAP Web IDE Full-Stack version is simple if you follow these tips:
- Understand the differences between the versions.
- Enable SAP Web IDE Full-Stack in your account.
- Choose a migration tool.
- Learn to migrate a shared project.
- Become familiar with Grunt.
- Enable additional features.
- Perform post-migration manual steps.
- Organize your projects in different workspaces.
Tip #1. Before starting the migration process, understand the differences between the SAP Web IDE versions.
In the new SAP Web IDE Full-Stack version, you can enjoy all the tools for developing SAPUI5/SAP Fiori applications you use in the current Web IDE. Also, project migration has no impact on your code.
Still, there are a few differences between the versions that you should be aware of.
Tip #2. Enable SAP Web IDE Full-Stack in your account.
This step is relevant for enterprise accounts only. In trial accounts, SAP Web IDE Full-Stack is already enabled.
Follow this procedure to set up your SAP Cloud Platform account so developers in your organization can start developing applications with SAP Web IDE Full-Stack.
Other account configurations you made for SAP Web IDE (like destinations and cloud connectors) are reusable in SAP Web IDE Full-Stack as is.
Tip #3. Decide which migration tool is better for your project.
You can migrate a project to SAP Web IDE Full-Stack either by using the Migration Wizard or by a regular Git clone operation. Consider the following to decide which method is most suitable for you:
- If you have several projects in your current Web IDE workspace and you would like to migrate them in batch, use the Migration Wizard.
- If your project is stored in a Git repository and you are not working on it right now (and therefore it does not appear in the Web IDE workspace), use the Git clone operation.
- If you have a project that you are working on together with your colleagues, read Tip #4 which explains how to migrate a shared project.
Tip #4. Learn to migrate a shared project.
If you are developing a project as a team and share the sources via a Git repository, we suggest you arrange the migration process as follows:
Step 1. In SAP Web IDE, all project contributors commit and push their changes to the Git repository.
Step 2. In SAP Web IDE Full-Stack, all team members adjust their user preferences including enabling required features.
Step 3. In SAP Web IDE Full-Stack, a representative of the team clones the project and, if needed, adjusts it as described in the Migration procedure. Then, the representative commits and pushes the generated and updated files to the Git repository.
Step 4. In SAP Web IDE Full-Stack, all team members clone the migrated project to their workspaces and continue working as usual.
We recommend that all developers working on the same project use the same SAP Web IDE version. If you choose different cloud versions or use the personal edition together with the full-stack development version, all changes to the project settings must be copied manually.
Tip #5. If you use the SAPUI5 Client Build in SAP Web IDE, become familiar with Grunt.
To know if this tip is relevant for your project, in SAP Web IDE open Project Settings and select the Project Types option. If the SAPUI5 Client Build checkbox is selected, then this is for you.
In SAP Web IDE Full-Stack, proprietary SAPUI5 Client build functionality is not available anymore. Instead, you can use open source technology: Grunt.
“Tasks are the modules that perform a specified job. They are defined in the Gruntfile. Developers can load predefined tasks from existing Grunt plugins and/or write custom code to define their own tasks depending on their requirements.”
To use Grunt in a project, two specific files need to be created in the root directory, namely package.json and a Gruntfile.
- package.json– contains the metadata for the project including name, version, description, authors, licenses and its dependencies (Grunt plugins required by the project).
— from Wikipedia
If your project is configured to use SAPUI5 Client Build, the files required to run the Grunt build are generated automatically during migration by one of the methods described in Tip #2. This produces the same output as the SAPUI5 Client build. You can use this best-practice configuration or extend the build as needed.
If your project is connected to Git, submit and push the generated Grunt files to your repository.
For more details on Grunt in SAP Web IDE Full-Stack, see Building Applications.
Tip #6. Before migrating your project, enable the required additional features in SAP Web IDE Full-Stack.
Optional plugin capabilities are provided by features in the SAP Web IDE Full-Stack version. If you use optional plugins in the current Web IDE, you should enable the corresponding features manually. For more information, see Enable Additional Features.
If you developed a plugin in SAP Web IDE, you will have to convert it to a feature as described in the Creating Our First Feature tutorial in the SAP Web IDE SDK.
If your project is connected to Git, you must commit and push to your Git repository the following files and folders that are generated or updated during migration regardless of the method you choose (see Tip #3):
- .che folder:
SAP Web IDE Full-Stack stores the project metadata and settings in a special system folder called .che. This folder is hidden by default. During migration, this folder is generated from the .project.json file that is no longer in use in SAP Web IDE Full-Stack.
- package.json, package-lock.json, Gruntfile.js, and .npmrc files:
If you used the SAPUI5 Client build in SAP Web IDE to minify and bundle files before deployment, these files are created in your project to enable the Grunt build. For more details on Grunt in SAP Web IDE Full-Stack, see Building Applications.
- If your project contains an ESLint configuration file .eslintrc, the “customRulesPath” property will be removed from it. The custom rule definition path will be stored in the .che If the “customRulesPath” property points to your custom rules definition file, the corresponding field in the .che metadata will be updated accordingly.
Depending on the type of your project, you may need to do another 1 or 2 small post-migration steps. For the details, please refer to the Migration procedure.
If you have several projects in your workspace, you will enjoy our new functionality that allows you to manage multiple workspaces and have them open in different browser tabs at the same time. With multiple workspaces, you can better organize your space by splitting projects in any way that suits you, for example by topics or customer domains.