chore(atomic): split create-atomic and its template altogether

[louis-bompart]

Motivation

In npm/cli#4518, I found out that 'sub-packages' with npm workspaces are not supported.

Decision

From there two solutions:

1. Do not use a subpackage for the template
2. Remove the subpackage occurrence

Pro for 1:

• Hierarchy stay the same
• The hierarchy represents better what's shipped to the end-user.

Con for 1:

• It would require dedicated scripts to integrate with our monorepo architecture.

Pro for 2:

• Smaller packages, with smaller jobs, making them more understandable.
• It works nicely with our monorepo architecture

Con for 2:

• Opposites of pro for 1.

Conclusion

I chose to go with option 2 because it was really simpler to put in place, and I think long-term it will help to distinguish between the 'leg-work' done by the generator, and what's actually generated.

It's important to note that the 'private' fields of the packages did not change, meaning that the template is still unpublished and that it's still bundled with @coveo/create-atomic, so no changes for the end-user.

Testing

No logic changes, the bundling process will be tested by the CI.

[github-actions]

Thanks for your contribution @louis-bompart !
When your pull-request is ready to be merged, check the box below to merge it

• Merge!

[github-actions]

Pull Request Report

PR Title

✅ Title follows the conventional commit spec.

[ThibodeauJF]

Funny how snyk got us there, template shouldn't even be a sub-package 😄

[louis-bompart]

On hold, waiting for npm/map-workspaces#32 to be merged & released. Then for npm/cli to update its dep and release.

[louis-bompart]

Funny how snyk got us there, template shouldn't even be a sub-package 😄

Yeah, it is true that from a technical standpoint this is unnecessary, one could even say silly, I totally agree.

However, the boons it brings outweigh the cost by far imo; thanks to this pattern we are able to ensure the template we ship to our customer is using 'just the right' versions: not the past one, nor the future one.

Dependencies bundled/related to the template are also kept to date, and we also ensure that there are no malicious dependencies shenanigans going on.

The sub-packaging also allows the template to be 'just right' on publication thanks to topological releases.