very_good_cli

very_good_cli copied to clipboard

Description org-name is not accepted when given a single identifier

Steps To Reproduce For creating app with org name com.example we use very_good create --org-name com.example example but this creates an app with applicationId com.example.example which actually should have been com.example

If very_good create --org-name com example is used, it is not accepted as the identifier required 2 parts between .

flutter create --org com example creates the valid required applicationId com.example

Expected Behavior very_good create --org-name com example should create an app with applicationId com.example

hi @toufeeqahamedns 👋 thanks for the heads up!

For now, our CLI requires an organization domain, which is formatted as <domain>.<organization>.<project_name>, I don't see a case where creating a project with a <domain>.<project_name> format is required.

Android, for example, uses the Java package naming conventions. So I don't know if there's an error when uploading to Play Store or App Store if the package name doesn't follow these conventions.

Maybe you can provide more context about these aspects?

Hey @marcossevilla, thanks for highlighting on Java Package naming conventions, the guidlines defined accept identifiers with 2 parts.

The <domain>.<project_name> would be very much helpful when you have the project say google.com and want to use com.google as the identifier

Also as the flutter create and both native android and ios project setup wizards allow to create the projects with <domain>.<project_name> it would be good if very_good create support it as well

I think if you have google.com as org_name it would miss the project_name, like com.google.gmail for example.

What we try to achieve with very_good_cli it's to have the standardized formatting of <domain>.<organization>.<project_name>.

Tagging @felangel and @jorgecoca to have some second thoughts on supporting this alternative.

I think rather than passing an organization name in, you should just be able to pass whatever bundle id you want in. I've been so confused when generating new projects and the cli tool appends the project name to the organization name I passed in. I'd much rather just pass in the bundle id instead of VG CLI trying to be smart enough to compose it from the organization name and project name (because sometimes the project folder name is different from the name i'd use in the bundle id).

I think if you have google.com as org_name it would miss the project_name, like com.google.gmail for example.

What if the org_name is your project name, as in google.com being the project and also the org name itself.

I'd much rather just pass in the bundle id instead of VG CLI trying to be smart enough to compose it from the organization name and project name

This would be a much better option

I agree with @definitelyokay, using the bundle ID would be better than having the org_name and project_name composing it. I'm just doubting about the usage of org_name, if it's used solely on another part and if this change would break that usage. Labeling as investigating as this may require to map where org_name is used. 👍

I'm not sure if this would be considered a separate issue, but 4 part bundle identifiers also have issues.

very_good create --template flutter_plugin --org-name com.example.subdomain.foo foo places the android class in the wrong dir (not sure if that is the only issue, but the only one I have encounter so far).

It results in an error:

The plugin `foo` doesn't have a main class defined in
/foo/foo_android/android/src/main/java/com/example/subdomain/foo/Foo.java or
/foo/foo_android/android/src/main/kotlin/com/example/subdomain/foo/Foo.kt. This is likely to due to an
incorrect `androidPackage: com.example.subdomain.foo` or `mainClass` entry in the plugin's pubspec.yaml.

If you are the author of this plugin, fix the `androidPackage` entry or move the main class to any of locations used
above. Otherwise, please contact the author of this plugin and consider using a different plugin in the meanwhile.

I believe com.example.subdomain.foo follows the Java package naming conventions shared above.

a package name begins with the top level domain name of the organization and then the organization's domain and then any subdomains, listed in reverse order.

Edit: In addition to the class being in the wrong location, I believe the pluginClass is misnamed in the pubspec.yaml as well.

hey all! did a small POC of this change to see what we need to change in order to deprecate org_name + project_name to form a bundle ID/package name and just use project_id, here's what I found:

• org_name let's us format the project_name correctly to form a compliant bundle ID and package name:

Android: com.example.veryGoodCore 👉 {org_name}.{project_name in camelCase} iOS: com.example.very-good-core 👉 {org_name}.{project_name in paramCase}

• creating a project ID property that has all the bundle ID/package name can be difficult to parse for both types of identifiers.
• there shouldn't be a problem if we use project_id as path to our MainActivity.kt file on Android.

what we can do:

• allow org_name to be just 1 part so we can concatenate the project_name and have 2-part identifiers, e.g: very_good create gmail --org-name google
• create bundle_id and package_name properties so we can use them as needed in their respective projects

leaning towards allowing 1 part for org_name as it would involve less impact to the existing implementation and there's some redundancy if we maintain a project_id and org_name at the same time for specific use cases. let me know what y'all think!

Hey @marcossevilla , thanks for working on POC, I strongly agree with going ahead with the first approach defined as this is also the case with flutter create

Would like to hear any suggestions from others.

hey all! did a small POC of this change to see what we need to change in order to deprecate org_name + project_name to form a bundle ID/package name and just use project_id, here's what I found:

• org_name let's us format the project_name correctly to form a compliant bundle ID and package name:

I'm not sure I fully understand what you mean. Part of the issue is that bundle id's and the folder name where you want to store the project (i.e., the name you give very_good_cli) are not necessarily correlated. In my opinion, Very Good CLI should let you specify an exact bundle id, pretty project name, and folder name all independently. If you don't specify the bundle id or pretty project name, it should infer those from the folder name.

allow org_name to be just 1 part so we can concatenate the project_name and have 2-part identifiers, e.g: very_good create gmail --org-name google

What do you mean by just 1 part exactly?

there's some redundancy if we maintain a project_id and org_name at the same time for specific use cases.

Also, not sure what you mean by this either.

I'm not sure I fully understand what you mean. Part of the issue is that bundle id's and the folder name where you want to store the project (i.e., the name you give very_good_cli) are not necessarily correlated. In my opinion, Very Good CLI should let you specify an exact bundle id, pretty project name, and folder name all independently. If you don't specify the bundle id or pretty project name, it should infer those from the folder name.

The issue is that Very Good CLI uses org_name and a formatted project_name to create bundle ID (iOS) and package name (Android). The formatting for each platform is different as they have different casing and handling these can involve (1) having two separate variables to ask for depending on casing or (2) having one variables and parse it, but this leads to bad formatting because of collision of two different casings (com.example.app uses dot.case and com.example.myApp uses dot.case and camelCase on the current project_name part). More context here.

What do you mean by just 1 part exactly?

org_name currently supports two parts: com.google for example. One part would mean com without .google is supported.

Also, not sure what you mean by this either.

If we have a project_id variable that represents the bundle ID and package name for the project's platforms, we'd still need to maintain org_name for specific cases like the path to this file.

@marcossevilla Thanks for taking the time to explain!

If we have a project_id variable that represents the bundle ID and package name for the project's platforms, we'd still need to maintain org_name for specific cases like the path to this file.

Wouldn't the project name be the right-most section of the bundle id? i.e., for a bundle id com.domain.subdomain2.subdomain1.myAppId, the project name is machine-inferable as everything after the last dot ., myAppId.

org_name currently supports two parts: com.google for example. One part would mean com without .google is supported.

If I understand correct, that's one of the current shortcomings with very_good_cli. Org names should be able to support more than 2 parts, because AFAIK org id's like the aforementioned com.domain.subdomain2.subdomain1 should be perfectly valid. That is, unless I'm wrong about the Java package naming convention. (Interestingly enough, Java doesn't allow hyphens in package names. Also, Oracle has an example package name on this page showing a package name with several subdomains.)

The formatting for each platform is different as they have different casing and handling these can involve (1) having two separate variables to ask for depending on casing or (2) having one variables and parse it, but this leads to bad formatting because of collision of two different casings (com.example.app uses dot.case and com.example.myApp uses dot.case and camelCase on the current project_name part

Can you explain a bit on the collisions? I think I almost see what you're saying, but you've dug into this far more than me. I am hoping there is a deterministic solution to this with minimal effort on the end-user's part.

Revisiting this and we should be able to support org names of variable length. Adding this to triage 👍

Very Good CLI currently supports org names of variable length so that issue should already be addressed.

Regarding the original issue of not including appending project name at the end of the bundle/application id, this is how the Flutter Tools work as well. If you run flutter create example --org com.example the generated project's applicationId is "com.example.example".

We prefer not to diverge from the existing behavior because that would likely cause more problems/confusion. Feel free to adjust the bundle/applicationIds after project generation if the generated IDs don't align with your expectations.

Closing for now since there are no actionable items for us to take on at this time but feel free to comment with any follow up questions and we're happy to continue the conversation 👍

We've discussed potentially adding a --applicationId to provide developers the ability to override the value.

I am trying to wrap my head around all the discussion here still, so please, let me know if I am missing something.

I don't think that creating a --applicationId parameter that overrides org_name.project_name will work as expected as that will generate an invalid package/folder name for android.

For example, we use org_name to generate the folder for the kotlin source:

And then org_name.project_name to generate the package for the MainActivity.kt.

So, if the value on applicationId differs too much from that pattern, the generated folder structure and package name will be invalid.

If I understood correctly, and please correct if I am wrong @definitelyokay, the biggest issue is that org_name.project_name may generate an unwanted result for the iOS bundle id.

Since this seems to be specifically related to iOS, what if instead we created a customBundleId argument that would override this value on iOS, since the current standard seems to make sense for Android?