November 2020 Answer
Converting from 1GP to 2GP is in Developer Preview in the Winter '21 (Oct 2020) release. You can join the Partner Community group which has all of the instructions for getting your Packaging Org enabled to pilot the functionality:
Previous Answer (...
It is the company Name in your DevHub org that is used for App publisher name.
Navigate to the Set up > Company Profile > Company Information in your DevHub and next package you generate will have this as the Publisher Name.
For Unlocked packages, you can revert a class from global to public or even to private and it should allow you to do it fine because it simply does not matter.
2GP Managed Packages
You can downgrade an Access modifier of a class from global to public or even private provided you create a new package version from the source with no ancestry. ...
I'll start this answer by recognizing that questions which solicit opinions, rather than objective answers, are frowned upon on StackExchange.
Having said that, the question was framed beautifully and this is an important topic.
I've been giving this a lot of thought lately. I'm hopeful that I can provide a constructive response based on my experience ...
After carefully checking the JSON source, I realized that the dependencies were out of order. You must list the dependencies in the order that they depend upon each other.
In other words, the (incorrect) source looked like:
This is part of the critical update documented here https://releasenotes.docs.salesforce.com/en-us/spring20/release-notes/rn_apex_publicConstructorsInMgdPackages.htm?edition=&impact=
Specifically "Apex classes contained in second-generation packages can instantiate public classes from other packages in the same namespace only if they are annotated @...
The best practice is to package up your connected app along with the other components in 2GP.
Now the way you package up the Connected App in 2GP is different, I will go down the steps here,
Create a 1GP Managed package in your org where you have the namespace. This package can include only the Connected App. The package needs to be Managed and Released.
I do not recommend using Custom Profiles in managed package (except if you are distributing the app as OEM app) as it requires a Mapping during installation which is an additional step that admins may miss.
Permission sets are easier to build and manage.
You can find some best practice here:
Permission Sets and Profile Settings in Packages
I just ran into the same issue. Trying to install my namespaced package into a scratch org with the same namespace.
You need to create a scratch org without a namespace using the --nonamespace flag and install your packages in there.
Namespaced scratch orgs should be used for development work on a package.
Non-namespaced scratch orgs should be used for ...
I build 2GMP for client who has many customers installed their previous 1GMP version of the package.
Respectfully, you and your client have made a strategic error here. It would've been far cheaper and guaranteed a better customer experience if you'd created a new 1GMP version.
Is there any way to implement a smooth customer migration from 1GMP to 2GMP?
As this mechanism is still beta (I added the bolding here):
As a beta feature, Second-Generation Managed Packages is a preview and
isn’t part of the “Services” under your master subscription agreement
with Salesforce. Use this feature at your sole discretion, and make
your purchase decisions only on the basis of generally available
products and ...
At this point, no. Packages, and package versions, cannot be deleted. There's an Idea you should go vote on. Note that you can deprecate packages, which does help with accidentally installing wrong versions, but for now, you'll have to live with your mistakes (by correcting them in a future version). Also, make sure you leave your feedback with the DX team ...
If you have enabled the ExperienceBundle Metadata API in the Dev Hub and you're still getting this error, remove the <networkMemberGroups> from the Network file of your Community. Due to a bug this doesn't work when combined with the ExperienceBundle, and it will throw this (nondescript) error.
The packaging for a second-generation package takes place in a "behind-the-scenes" scratch org that Salesforce calls a build org. That build org needs to be configured with the right features in its definition file, which is provided to force:package:version:create with the [-f DEFINITIONFILE] argument.
You can potentially reuse an existing scratch ...
I have not tried this, but I don't think you could do.
The Salesforce DX Developer Guide:
Generate the Package
You can’t change the package namespace or package type after you
create the package.
For 1 and 2nd items, the work is in progress and cannot publicly disclose the dates.
I recommend you reach to your partner account manager or if you are an ISV reach to your ISV Technical Evangelist to get some idea on when it is going to be released and process.
For your third question below,
Is it too late to migrate to second-gen if I've started building ...
First, some definitions:
Developer Edition Org
A Developer Edition (DE) Org is used for development of personal projects and AppExchange products using First Generation Managed Packaging (1GMP).
A Production Org (prod) is used as your primary business org. This is a paid org (or free for some non-profits), both for businesses using Salesforce ...
After contacting Salesforce, I had confirmation that Version is, to this day, not supported in 2GP, which caused the issue described here.
Update Oct.2021: still not supported.
The "least worst" workaround I found so far would be to generate an ApexClass w/ a static field or CustomMetadata that would contain the version, in a CI/CD.
Communities are not packageable for 2GP packages.
As an unlocked package yes you can package up the ExperienceBundle (there are some known issues with ExperienceBundle as well on known issue site so do not recommend it as of today) but not as a 2GP yet.
The only recommended way to package communities is via the "Bolt Solution" which allows you to ...
After a painful 2 week trial and error dance with Salesforce Support (Case: #26307915), we learned that we have to do something very unintuitive.
It's a setting in the Dev Hub org which needs to be enabled.
Setup > Communities Settings > Enable ExperienceBundle Metadata API
We don't know why and it even worked after we disabled it.
I got rid of the errors:
Dependent class is invalid and needs recompilation
By adding --definitionfile config/project-scratch-def.json to the command:
sfdx force:package:version:create --package "My App" --postinstallscript AppInstallHandler.cls -w 10 --definitionfile config/project-scratch-def.json --loglevel TRACE
Now I am getting a different ...
This is because you have a Connected Apps source in your 2GP package.
There is a unique way to package this up and I have answered it here
Get rid of the Connected Apps file from your project directory and make sure you follow the steps here
The Special Behavior of Components in Packages documentation states that:
Changes to standard picklists can’t be packaged and deployed to subscriber orgs and picklist values deleted by the developer are still available in the subscriber’s org.
So - in theory - I should not be able to generate that package version at all.
I added a new custom field to the ...
G'day folks. Apologies for being a bit late to this discussion.
@lightxx -- There are pros and cons about separating the fflib classes out to a new package.
All things being equal, it makes sense to isolate the fflib classes into two different packages; one for Apex Mocks and one for Apex Common.
Having said that, there is currently a couple of downsides. ...
Edit: This is a Known Issue. Make sure you mark "This affects me" if you want to be updated when this updated.
You need to annotate the members if you want them to be directly accessible:
@namespaceAccessible public Boolean success = false;
@namespaceAccessible public String message = '';
The docs specifically state:
The @namespaceAccessible makes ...
There's no absolute foolproof way, but you can give yourself some assurances. First, set the Default Dev Org before you start working. You'll see which org you're connected to in the lower-left corner:
Almost all VSCode commands work on the default org, as well as commands in the terminal. The only exceptions are those that explicitly use a Dev Hub Org, ...
Just heard from SF...
The point is that the only suffix supported in LWC is '__c' so far.
It is not yet documented in Importing Limitations section here: https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.data_wire_service_about.
Importing Platform Events (with '__e' suffix) should soon be added as a part of Importing ...