4

I have a need for multiple .forceignore files in my Salesforce DX project. The reason for this is that there are files that I would like to have in development (scratch orgs) but I do not want to deploy back to the packaging org when we are ready to build a new version.

Before trying to use a .forceignore file to exclude files when deploying, I was just manually removing the references from the package.xml but this was time consuming and won't scale well. I then realized I should just be using a .forceignore to do this.

My question is if anyone has run into the same scenario and what was your solution? One solution I thought of is just to comment out the lines when pushing to scratch and uncomment them when deploying but this isn't very elegant. Any advise or experience is appreciated.

Improve this question
2
  • 2
    There doesn't exist one yet. You may like to upvote this idea
    – Jayant Das
    Commented Feb 14, 2019 at 21:55
  • I was afraid of that...
    – Zack Walton
    Commented Feb 14, 2019 at 22:04

2 Answers 2

Reset to default
2

So one thing I hadn't fully understood/embraced that helped with this was using the ISV Falcon Template setup as defined here: https://github.com/sfdx-isv/sfdx-falcon-template

It is setup to have multiple folders under the core source directory - one with the name of the namespace, another called unpackaged:

enter image description here The reason this helps with this issue is that anything under the source folder is deployed, but when you come to convert the code back to MD to deploy to packaging, you just can convert the source code in folder with the namespace, and deploy that.

Now it is not perfect - e.g. if you add something new in the scratch org and do a pull, it will pull it back into the default\main, which is typically the namespace folder. But if you move it to the unpackaged folder, DX will know to pull any subsequent updates there. So once you get the structure setup, it is much easier to keep the packaged code in a separate place, and be confident that any deployments back to the packaging org only contain stuff you want to include in the package.

I recommend watching the intro video on the readme to get a better idea on how it works.

Improve this answer
2
  • Thanks I will look into that. I think we are going to try to convert to using second generation packaging soon. Do you know how this will work with that?
    – Zack Walton
    Commented Feb 15, 2019 at 16:41
  • 1
    Based on the video, it sounds like the structure is actually designed for Gen 2 - so I think it looks for the namespace folder to build the package - but that is speculation on my part. I am also a bit skeptical that Gen 2 will be ready for prime time any time soon...but looking forward to being proved wrong.
    – BritishBoyinDC
    Commented Feb 15, 2019 at 19:48
0

You should not deploy in a non-scratch org using sfdx force:source:push , you need to use a package.xml file so you can identify item by item the content of your managed package ( and avoid unexpected items who could "pollute" your package ).

Once you built your package.xml file, to deploy to your packaging org you can use :

Improve this answer
6
  • Could mr downvote at least enlight me about why my answer is not appropriate ?
    – Nicolas Vuillamy
    Commented Feb 15, 2019 at 16:20
  • I do not deploy to the packaging org using sfdx force:source:push. I use sfdx force:source:convert which creates a package.xml and then sfdx force:mdapi:deploy to deploy it to the packaging org. the point of the .forceignore is to exclude files from the package.xml which I explain is how I am doing it currently.
    – Zack Walton
    Commented Feb 15, 2019 at 16:39
  • 1
    I implore you to read through some documentation developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/…. Your answer was telling me not to do something although I never said I was doing that in the first place. Don't be mad that I didnt think your answer to be relevant or helpful
    – Zack Walton
    Commented Feb 15, 2019 at 17:11
  • If you wanted to change your answer to be relevant to my question then I would be happy to take the down vote away. Currently I think it is not useful so I feel as if I am using the downvote properly.
    – Zack Walton
    Commented Feb 15, 2019 at 17:35
  • 2
    I agree that this use of a down vote is appropriate, if unnecessary. Just as, if you feel the question lacked critical details, it would be appropriate to vote that post down (as long as you are not doing it just to retaliate). What is not appropriate or acceptable is to be rude. Nicolas, I have flagged your posts as unfriendly/unkind. Please remember to use civility when interacting with other users on this site.
    – Adrian Larson ♦
    Commented Feb 15, 2019 at 19:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .