I'll be building my first managed package as part of a client project. Because we're writing it on behalf of another company, eventually it will be released under a namespace that belongs to them, and at some point in the future on AppExchange under their name. By spring/summer of this year they'd like to see it available for private distribution to a few of their customers.

I've got some Salesforce development experience behind me, but have had zero opportunity to explore Salesforce DX because it has never been appropriate for the partner projects I've been brought into. With this project though, we do have the choice of starting from scratch using either a traditional "develop in a DE org, then migrate to beta packaging org, then finally to golden" flow, or going full DX and diving into 2nd-generation packaging.

The fact that the app won't belong to us could be a minor complication. Our devs are not going to have CRM licenses on our client's business org. My understanding is that with 2nd-generation packaging you need to link the namespace to one Dev Hub and then it can't be moved.

Anyway I just wanted to read the room on this. I'm embarking on this project at a time when older development tools (like the original Force.com IDE) are being neglected while newer ones are still pretty bleeding-edge. What's a dev to do? Is a DX approach fully-baked enough to actually use to put out a product in the near term? Possible pitfalls of taking that route and/or doing it the "old way"?

If we go with DX are there multiple divergent ways to do this?

EDIT, 2019-08-28: Just an update. We built the package for the customer using SFDX and 1st-generation packaging. It has now passed Security Review and is on AppExchange! 🎉 So that's been a very interesting experience.

At the moment, Winter '20 is slated to be when 2GP goes GA. We have not yet seen documentation of how to transition to 2GP but we look forward to seeing more.

1 Answer 1


DX Packaging and DX ISV development are two different features. You won't be able to use either of them, but that doesn't mean DX is useless. DX Packaging is like a non-namespace managed package, meaning it can be created and upgraded and installed in various orgs you control easily without the limitations of managed packages. DX ISV development allows you to create scratch orgs with a namespace, making it easier to deal with the discrepancies between developing in a non-namespaced org. You'd have to deal with this limitation in the Force.com IDE as well, so there's no benefit to sticking to the Force.com IDE from this perspective.

However, DX is a lot more than DX Packaging and DX ISV development. It ties in nicely with more code systems, including VS Code and the new Force.com IDE 2. It lets you export related data into a set of files that you can then import into other orgs. You can't do this with the Data Loader, so it's arguably nicer for developers than the Data Loader (note: it does not replace the Data Loader, but serves a specific niche the Data Loader does not).

It also makes it easier to use a git repository. You can use scratch orgs from your Dev Hub org to make it easier to push and pull changes much faster and more accurately than you ever could in the Force.com IDE, with much less manual messing around with packages and raw XML files in the Force.com IDE or the Metadata Migration Toolkit. A single synchronize in my Force.com IDE for our production takes several minutes to complete, while a synchronize with DX takes typically one second after the initial push.

While you can't, at least not yet, use all of the latest and greatest features of DX, it's still much better than using the Force.com IDE. It's faster, and has more features designed to shorten the development cycle significantly. Also keep in mind that a Dev Hub org doesn't reflect the state of the Source of Truth; it's merely a place to authenticate users for scratch orgs.

This means that a developer can spin up a new org in just a few minutes with a single command-line operation instead of the traditional hour-or-longer waits associated with Developer Sandboxes. While there's some learning curve associated with DX as well, it mostly applies to older developers used to a different way of doing things. If you're still relatively new to the whole process, you may as well start off right and use DX.

The old way had a number of pitfalls, such as dealing with overwriting code and configuration, stale developer orgs, spinning up new developer orgs, loading test data, and more, many of which have been addressed by DX. You would be remiss to ignore DX by saying that simply because one little feature isn't usable, you may as well throw the whole thing out.

  • Thanks for the reply. When you say "You won't be able to use either of them" regarding DX Packaging and DX ISV development, is that because they're not going to be GA soon enough? Is the limitation that I just develop the package with DX as if I'm developing for a single org, and then migrate it the code to a beta packaging org when I want to test packaging it?
    – Charles T
    Jan 16, 2018 at 13:08
  • @CharlesT The features are already GA. The namespace-sharing feature won't work for your use case, since you don't "own" it. DX Packaging isn't really meant for your use case either, but it might work; I suggest you spend a bit of time researching it. Overall, though, it'd basically be like classic ISV development but with a source code repo, which is better than nothing at all. Migration to the packaging org could still use the DX command-line, but might need to be done by the client, depending on how you set things up.
    – sfdcfox
    Jan 16, 2018 at 16:25
  • Thanks for clarifying. Suppose that the client grants us use of "Salesforce Limited Access - Free" licenses in their production org so we can use their Dev Hub, and that we also have access to any necessary packaging orgs they'll need to own. Would that allow us to use the DX ISV Packaging features? I'm a bit confused with the mess of different information sources for the various generations and varieties of packaging, open betas vs GA etc.
    – Charles T
    Jan 17, 2018 at 5:08
  • @CharlesT Yes, the SLAF license should work just fine according to the docs. Beta You might want to read the ISVForce guide for additional details that are not covered in the main documentation. For Salesforce features, there's "closed pilot" (must sign up, limited audience), "closed beta" (larger audience), "open beta" (no sign up, known limitations), and "GA" (generally available).
    – sfdcfox
    Jan 17, 2018 at 5:17
  • Right. And I see that 2GP is currently listed as Beta. I don't know if that would bar me from using it right now on a package that we do intend to be released a few months from now.
    – Charles T
    Jan 17, 2018 at 20:08

You must log in to answer this question.

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