Loopback-next: [CLI]: Lb4 app - Project root directory default name split the number

[alcmontejo]

Steps to reproduce

$ lb4 app looback4-todo
? Project description: looback4-todo
? Project root directory: (looback-4-todo)

Current Behavior

No sure if this is by design, however it is a little strange. Project root directory default alter the initial project name if the first group name contains number., But if the number found in the last group, it works as expected.

eg:

• looback4-todo => looback-4-todo (altered)

• todo-looback4 => todo-looback4 (expected)

Expected Behavior

Project root directory default should persist the initial project name to avoid developer re-typing the initial project name, I think that is the purpose of providing default anyways to improve dev experience.

Link to reproduction sandbox

Can be reproduce during initial creation of the project through CLI.

Additional information

node -e 'console.log(process.platform, process.arch, process.versions.node)'

win32 x64 12.18.3

npm ls --prod --depth 0 | grep loopback

+-- @loopback/[email protected]
+-- @loopback/[email protected]
+-- @loopback/[email protected]
+-- @loopback/[email protected]
+-- @loopback/[email protected]
+-- @loopback/[email protected]
+-- [email protected]

Related Issues

_See Reporting Issues for more tips on writing good issues_

[hacksparrow]

Agreed, it is a little strange. We should not touch the numbers.

[achrinza]

Internally, the lb4 CLI uses lodash's kebabCase to generate the filename, and merges any dangling digit to the last word. Hence the expected result in todo-looback4 but not looback4-todo:

https://github.com/strongloop/loopback-next/blob/dd582856c8fa133fbc16dd9184a4f1b038baf5aa/packages/cli/lib/utils.js#L35-L37

[dhmlau]

+1 in keeping the project root directory unchanged. I encountered this situation a few times especially I tend to use the --yes option when scaffolding an app. :)

[bajtos]

Quoting from https://github.com/lodash/lodash/issues/2843:

Expected: string1 (maybe? - again… I couldn't find a spec)

_.kebabCase, like other casing methods, relies on _.words to separate compound words.
The specs are with _.words. After all, it'd be a bit goofy to duplicate the same test 6 times when it comes down to 1 method.

We treat numbers as separate in most cases:

'walk500Miles' // is treated as words "walk 500 miles"
'12ft' // is "12 ft"
'tooLegit2Quit' // is "too legit 2 quit"
'isISO8601' // is "is ISO 8601"

The exceptions are ordinals:

'1st' // is '1st'
'14th' // is '14th'

I checked few alternative packages (kebab-case and dashify), they don't support full range of Unicode characters (e.g. `Bajtoš'), which IMO means we cannot use them. Detecting unicode words properly is a tricky business, see https://github.com/lodash/lodash/blob/master/.internal/unicodeWords.js

[hacksparrow]

Fixed in https://github.com/strongloop/loopback-next/pull/6429.