Hey all,
We’ve just merged a change in CesiumJS that moves to let and const syntax-- ES6 features we can finally take advantage of now that we’ve dropped support for IE11.
If you’re just using CesiumJS by downloading release ZIPs or by installing it from npm, this won’t affect you at all. You can stop reading.
But if you have a fork of CesiumJS, you will find that the next time you pull from the upstream repo, many lines of code will have changed and you’ll have heaps of merge conflicts. The good news is, it’s very easy to avoid the conflicts if you follow the process below. Consider bookmarking this post now so that you can return to it when you’re ready to merge.
Similar to migrating after the transition to using prettier, to merge from CesiumGS/cesium starting with main today or with the 1.90 release in February, do the following:
- Fetch changes from the upstream
git fetch upstream . Replace upstream with the name of your git remote that points to the official CesiumGS/cesium repo.
- Create a new branch for your merge:
git checkout -b whatever-merge . This is not strictly necessary, but it makes it easier to start over if something goes wrong in this process.
- Merge the last commit before the transition into your branch:
git merge pre-let-const . Resolve any conflicts as you usually do.
- Commit the merge above.
- Merge the changes, accepting your own changes in all cases:
git merge post-let-const --strategy=recursive -X ours --no-commit Accepting yours is safe because this commit only changes variable declarations. At this point, you can safely commit (just note that CI will fail if you push to a branch with Travis enabled).
- Run eslint with the
fix option on the results: npm run eslint -- --fix.
- There may be cases that eslint cannot automatically fix. Manually fix them now and run
npm run eslint again to verify your fixes.
- Commit these changes.
- Merge main into your branch in order to pick up any changes in main that happened after the transition:
git merge upstream/main. You can also merge a release tag here instead of main , if desired. Resolve any conflicts as normal and commit; there shouldn’t be any conflicts related to let and const.
- Once you’re satisfied with the result, merge it back into your original branch, if you created a new one in step 2:
git checkout my-original-branch && git merge whatever-merge
8 Likes
Hi everyone,
I recently submitted another ES6-related PR to allow template literals. This allows you to use string template literals in CesiumJS code.
This change will be beneficial to 3D Tiles Next/ModelExperimental development, as these features involve dynamically generating lots of GLSL code.
Since this is another automated change (via eslint --fix) that affects many files, open branches can be updated with an almost identical process to the const/let change above. The only difference is the tag names (pre-template-literals and post-template-literals, I’ve highlighted these differences below.
Important: If you still need to apply the const/let changes to your branch, do those steps first to help the process go smoothly.
- Fetch changes from the upstream
git fetch upstream . Replace upstream with the name of your git remote that points to the official CesiumGS/cesium repo.
- Create a new branch for your merge:
git checkout -b whatever-merge . This is not strictly necessary, but it makes it easier to start over if something goes wrong in this process.
-
(different tag) Merge the last commit before the transition into your branch:
git merge pre-template-literals . Resolve any conflicts as you usually do.
- Commit the merge above.
-
(different tag) Merge the changes, accepting your own changes in all cases:
git merge post-template-literals --strategy=recursive -X ours --no-commit At this point, you can safely commit (just note that CI will fail if you push to a branch with Travis enabled).
- Run eslint with the
fix option on the results: npm run eslint -- --fix.
- There may be cases that eslint cannot automatically fix. Manually fix them now and run
npm run eslint again to verify your fixes.
- Commit these changes.
- Merge main into your branch in order to pick up any changes in main that happened after the transition:
git merge upstream/main. You can also merge a release tag here instead of main , if desired. Resolve any conflicts as normal and commit; there shouldn’t be any conflicts related to let and const.
- Once you’re satisfied with the result, merge it back into your original branch, if you created a new one in step 2:
git checkout my-original-branch && git merge whatever-merge
1 Like
Hi! Thanks for this information! I am wondering if the automatic glsl => glsl.js shader compilation could use the template literals as well? I think they still produce the “\n” format…