fix(atomic): possible @coveo/headless version mismatch

[ThibodeauJF]

https://coveord.atlassian.net/browse/KIT-1515

See this related PR for samples

Root problem

When installing @coveo/atomic, @coveo/headless is both a “subpackage” (@coveo/atomic/headless) and a dependency (@coveo/headless).

Stemming issues

1. Both versions can have a possible mismatch
2. The typescript of Atomic’s Headless points to @coveo/headless instead of @coveo/atomic/headless.
3. You start getting completions for both packages in VS code, because of the dependency. Not a big deal, but can be a bit annoying.
4. Using the CDN & npm packages could also lead to version mismatches.

Solutions

1. For issue # 1, by using lerna’s --exact option, it will ensure that the exact version is installed for our packages https://github.com/lerna/lerna/tree/main/commands/version#--exact
2. For issue # 4, there should be no major issues when building custom components with a different Atomic & Headless patch version, but there may be some internal bugs if it’s using different minor version (we should specify in the doc to stick to the same minor when using an hybrid CDN/NPM setup, and perhaps advise against it entirely). To fix this in the CLI project, we could either:
   1. Ensure the CDN path fits the installed minor (e.g. I have @coveo/[email protected] installed, CDN should be https://static.cloud.coveo.com/atomic/v1.34/atomic.esm.js
   2. Remove the hybrid mode and use the installed @coveo/atomic build (personally favoring that option, see PR)
3. For issues # 2 & # 3, removing @coveo/atomic/headless from NPM in our next major bump and only keeping it for the CDN is a possible fix. This will make better use of NPM without workaround when using NPM. A doc change will be required.
4. For issue # 2 replacing the path “@coveo/headless” with “@coveo/atomic/headless” in our declaration files for the Atomic package could do it.
5. For issue # 2 now in the CLI project, use a different path in the tsconfig mapping @coveo/headless to Atomic’s (see PR)

We could go for fixes # 1, # 2, (# 4 or # 5) for now and perhaps fix # 3 when we bump?

[github-actions]

Thanks for your contribution @ThibodeauJF !
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.

Bundle Size

File	Old (kb)	New (kb)	Change (%)
case-assist	194.4	194.4	0
search	272.7	272.7	0
product-listing	207.4	207.4	0
product-recommendation	191	191	0
recommendation	189.7	189.7	0

[olamothe]

We could go for fixes # 1, # 2, (# 4 or # 5) for now and perhaps fix # 3 when we bump?

Yep, that seems like the best approach following your analysis !

[ThibodeauJF]

@btaillon @olamothe

We could go for fixes # 1, # 2, (# 4 or # 5) for now and perhaps fix # 3 when we bump?

number 4 or 5 ?

[olamothe]

number 4 or 5 ?

I think 4 is the most solid solution that will work for people that also manually install/start a project (and not done through the CLI).

[ThibodeauJF]

Okay thanks, I'll make the rest of the changes in upcoming PRs

[louis-bompart]

For issue # 1, by using lerna’s --exact option, it will ensure that the exact version is installed for our packages https://github.com/lerna/lerna/tree/main/commands/version#--exact

I'm not sure if Lerna proceed topologically for the release, i.e., let's say I do a release where atomic and headless changes, will the new version atomic use the new version of headless?