Should provide sanitized identifiers based on input

[purplecabbage]

@tony-- has encountered some cases where the identifier is too strict in its lowest common denominator approach. It would be nice if the valid-identifier package could return a valid identifier, which could be used.

More from Tony and team here :

Windows (Identity/Name)
The name is an attribute of the Identity element in the application manifest file.
Must consist of of between 3-50 characters.
The identity/Name must contain only letters, numbers, the “-“, and the “.”.
Cannot end in a period.
The Identity/Name cannot be:
“CON"
"PRN"
"AUX"
"NULL"
“COM1” - “COM9"
“LPT1” - “LPT9"
Link: https://msdn.microsoft.com/en-us/library/windows/apps/dn423277.aspx (window 8.1)
Windows (Application/Id)
This field is updated with the text put into the Identity/Name field by Cordova. These fields have conflicting specifications so I have listed it here. I have hi-lighted the potentially conflicting requirements.
The Application/Id name in the application manifest file.
Must consist of between 1-64 characters
The Application/Id must contain only letters, numbers, and the “.”.
Each section must begin with an ASCII alphabetic character.
The Identity/Name cannot be:
“CON"
"PRN"
"AUX"
"NULL"
“COM1” - “COM9"
“LPT1” - “LPT9"

iOS (Bundle Id)
Is the BundleId of the application plist file.
Is a Uniform Type Identifier (UTI)
Contain at least two sections. Sections are separated by the period character “.”.
The bundle id must only contain letters, numbers, the “_”, “-“, and the “."
Should be organized in the reverse-DNS format.
Cannot end in a period.
Link: https://developer.apple.com/library/prerelease/watchos/documentation/IDEs/Conceptual/AppDistributionGuide/ConfiguringYourApp/ConfiguringYourApp.html#//apple_ref/doc/uid/TP40012582-CH28-SW2

Android (Package Name)
Is a name in the AndroidManifest.xml file.
Must have at least two sections. Sections are separated by the period character “.”.
Each section must have at least one character.
The first character must be lower case.
Each section must not start with a number
Each section must not be a Java keyword
Each section cannot start with the word “java”.
The package name must only contain letters, numbers, the “_”, and the “."
Cannot end in a period.
Android Link: http://developer.android.com/guide/topics/manifest/manifest-element.html#package
Java Link: https://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.1 (java 7)

[xmnboy]

Please relax this requirement!

This LCD (lowest common denominator) approach is particularly difficult to deal with when you have apps in stores that use conforming App IDs (for that platform) but those App IDs do not meet these strict LCD requirements. What you have done is create a situation where existing app owners cannot move to Cordova if they want to publish updates of their existing apps.

This issue also arises for existing Cordova users, who used an older version of Cordova to create an app, and used an acceptable App ID that was valid for that older version of Cordova but is not compliant with this stricter LCD App ID requirement. They are left out in the cold. They have a published app, created with an older version of Cordova, but cannot move to a later version of Cordova to enhance or update their app, due to this restriction.

I understand this approach may be a "convenient and easy" rule for the Cordova project, and it feels like the "right thing to do" when you're arguing for an ideal cross-platform app development tool, but this approach does not recognize the realities real developers face.

My request would be that you define a set of rules based on the platform, and apply that rule to the platform at the time of the build. A compromise would be to provide a "pluggable" App ID validator, so that build systems like ours (Intel XDK) could easily substitute an alternate App ID validation rule without having to modify the Cordova CLI tools, eliminating unnecessary re-engineering with each release of the Cordova CLI tools.

[purplecabbage]

I agree. Ideally what needs to happen is we need to separate the use of app/package id from uses of this value for namespaces ( which is where the strict checks matter )

I will look into relaxing the check to simply be a warning until we can resolve this correctly everywhere.