4

We want to switch to vscode but our git repo uses old source format and we don't want to convert this to new source format yet.This article talks about how to convert existing projects to new source format without losing git repo history but we don't want to do this, atleast, for sometime.

Here is what we are thinking of and need input from others if there will be any issues with this approach.

  1. Project exists in old format.
  2. Create new project in vscode and choose the option create project from manifest file.
  3. Make changes in vscode.
  4. When ready to commit, convert the new source structure to old structure with command sfdx force:source:convert. I played around with this command we can convert only the component that we touched and don't need to convert entire project.
  5. Go to folder(old source format) and commit from there.

If we are working on metadata type that did not change in new source format, we don't need to convert and simply copy file from new Project to Old Project and commit from there and no need to use command sfdx force:source:convert.

5

That's similar to what we do now and... no, it doesn't work, at least not well. If you do this, you will continue to make more work for yourself, and you will likely "never" get in to DX format. Conversion on any non-trivial project "all-at-once" is not trivial and not recommended. I tried once in our org and lost a month worth of work-hours trying to do this, while other developers were actively using "src" metadata format files, etc. Also, I should add that this is a lot more work over time than necessary.

If your goal is to use DX, the entire team needs to start at once and commit to it (no pun intended, I think). Create an empty DX structure and commit it to your repo. When you need to change a file, use git mv to move it to the appropriate DX folder(s), commit those changes, do work in VS Code, commit, and then deploy from DX. Lather, rinse, repeat until you're fully converted.

Once you start, everyone should use force:source:deploy/force:package*/etc to deploy. If you have a CI/CD, have it deploy metadata first, then DX afterwards. As you move your metadata over, you can eventually just turn off the mdapi deployments and strictly use DX deploy or package installs. Changing over time will eliminate the stress of trying to convert all at once and ease the transition.

  • 1
    Transitioning slowly into DX seems like a good idea. Also, thanks for suggesting git mv command, I am going to explore on this. Thanks! – javanoob Jan 29 at 21:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.