[Discussion] Socializing ng blueprint changes (changes to files generated by ng new in newer versions of the CLI)

[Meligy]

Hello,
I'm opening this as a discussion placeholder for socializing changes to the ng blueprint files.

There are certain files that most users wouldn't be expected to modify frequently for their own purposes (but still are expected to modify), and would benefit from upgrading when upgrading the Angular CLI.

Some examples:

• tslint config
• various tsconfig files
• karma config
• package.json (especially devDependencies)
• maybe also there's value in getting new defaults in .angular-cli.json files

In the past there have been two ways to notify users about this:

The first way was ng init. You could run that after CLI upgrade to simulate ng new, and it would override all your default files, which was considered destructive and harmful as even if you have git and use its diff, it can be confusing and the comparison to restore your own changes to files can be quite hard. This is still somehow available via passing the directory flag to ng new, but highly discouraged (and I agree).

The other better way that was introduced later was via manual updates to the CHANGELOG.md file. This worked very nicely, with a single caveat that I'm aware of, which is, since the recording the new blueprint changes was manual, it was not unusual to miss some of the changes, causing this way to be somewhat unreliable, although awesome when it works, and very helpful to developers not too familiar with the source code of the project.

Unfortunately we lost the manual notes when the project switched from CHANGELOG.md to Github Releases.

Is there a way to inject manual release notes in there?
Can it be used to get back the manual file changes that accompany CLI upgrade?

And of course: is there a way to make the manual recording of changes more likely to be complete?

[Meligy]

One idea I have is to have some file similar to the CHANGELOG.md file, which captures only the changes applied to ng blueprint files. It can be always set to master state, with a new heading with specific release number added right before releasing.

Then it can be a requirement for PRs that modify any files under /packages/@angular/cli/blueprints/ng to include an update to this file as well.

The idea of the file and PRs is to not add another release activity that makes releases more expensive, especially that also by release time it might be a bit late to capture all changes since previous release.

Release notes if they can be added to Github Releases (I think I saw them in other repos), can just link to this file.

But that's just one idea. Hoping better solutions can come from the discussion.

[filipesilva]

I think this is a pretty relevant topic. The files you listed are indeed things that users should try to keep up to date, but currently this is not trivial. It helps that updating them is not really mandatory though.

Soon we're moving to @angular-devkit/schematics (#6593, #7090). This will make the matters a bit more complicated.

But it also might help. Schematics is pretty powerful, perhaps we could isolate the configs and that could be a schematic of it's own.

@Brocco thoughts?

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}