feat(cli): improve file structure for generated datasources (json/ts)

[raymondfeng]

Improve file structure for datasources - extracted from #4051

Triggered by microsoft/TypeScript#34761

See #4051 (review)

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

👉 Check out how to submit a PR 👈

[raymondfeng]

My response to #4051 (review):

Two options are proposes so far:

1. Rename the *.datasource.json files to avoid conflict.
   • *.config.json (implemented by the current PR)
   • *.datasource-config.json (proposed by @bajtos)
   • *.datasource.config.json (I had this convention before *.config.json)
2. Inline the json config into *.datasource.ts file

I see a 3rd option:

1. Keep a separate json file for datasource configuration
2. Improve datasource booter to use app.configure() to register configuration for datasources
3. In *.datasource.ts files, use @config to inject configuration into the class

[raymondfeng]

I'm proposing to rename *.datasource.json to *.datasource.config.json as the short term solution so that we can fully support TypeScript 3.7.x soon.

[raymondfeng]

@bajtos Please review.

[dhmlau]

LGTM.
Does it consider as a breaking change?
Also, we probably need to update the loopback4-example-shopping accordingly. Thanks.

[raymondfeng]

@dhmlau See loopbackio/loopback4-example-shopping#365.

I don't see it as a breaking change as existing code continues to import from *.datasource.json. The PR only impacts how datasource files are generated.

[bajtos]

I'm proposing to rename *.datasource.json to *.datasource.config.json as the short term solution so that we can fully support TypeScript 3.7.x soon.

👍

In *.datasource.ts files, use @config to inject configuration into the class

I was thinking about @config too, let's leave that out of scope of this pull request though.

[bajtos]

Does it consider as a breaking change?

I don't consider this as a breaking change for the reasons explained by @raymondfeng above.

However, I think we need to clearly communicate this change and explain our users how is it affecting their exiting projects, what is the migration path and how urgent the upgrade is.

I think a short blog post (independent of our milestone blog) would be ideal.