Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(headless): add case-assist sub package #717

Merged
merged 17 commits into from
Apr 23, 2021
Merged

chore(headless): add case-assist sub package #717

merged 17 commits into from
Apr 23, 2021

Conversation

samisayegh
Copy link
Contributor

This PR refactors the rollup file to make it easy to add sub-packages to headless.

@@ -0,0 +1,36 @@
# Adding a sub-package
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@github-actions
Copy link

github-actions bot commented Apr 15, 2021

Pull Request Report

PR Title

✅ Title follows the conventional commit spec.

Bundle Size

File Compression Old (kb) New (kb) Change (%)
dist/browser/headless.js bundled 463.2 463.2 0
minified 194.9 194.9 0
gzipped 56.4 56.4 0
dist/browser/headless.esm.js bundled 449.4 449.4 0
minified 248.6 248.6 0
gzipped 62.1 62.1 0
dist/browser/case-assist/headless.js bundled 0.5 0.5 0
minified 0.3 0.3 0
gzipped 0.2 0.2 0
dist/browser/case-assist/headless.esm.js bundled 0.1 0.1 0
minified 0 0 0
gzipped 0.1 0.1 0
../atomic/src/external-builds/headless.esm.js bundled 449.4 0 -100
minified 248.6 0 -100
gzipped 62.1 0 -100

@@ -0,0 +1,3 @@
export function hello() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove I guess ;)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I think it would be nicer if we had:

packages/headless/src/case-assist/index.ts

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will empty the file and keep just a comment for git.

For creating a case-assist directory, I feel this divides case-assist functionality into it's own branch of the tree, which I don't think we should do.

Currently it looks like this:

headless_directory_structure

I think we should keep controllers together, features together, and group functionality under those concepts, rather than by sub-package. Some controllers will be used by multiple packages after all.

controllers/
    controller1
    controller2

If the goal behind the directory is to have the word index in the file name though, we could call it:

case-assist.index.ts

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edit: readding a dummy export because rollup throws an error otherwise.

packages/headless/package.json Show resolved Hide resolved
packages/headless/pkg/case-assist/package.json Outdated Show resolved Hide resolved
@@ -0,0 +1,10 @@
{
"name": "case-assist",
"version": "1.0.0",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Euhmmm... how will that work exactly with lerna + semantic commit ?

What does that "version" represent ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will remove it, it's a result of running npm init to generate this file.

This package.json is just a way to tell IDEs and bundlers where the js and typedefinitions are located for a sub-package. The source of truth for the version published to npm is the one in the headless root package.json


1. Build the headless project: `npm run build`.
2. Create a tarball: `npm pack`.
3. Install the tarball as a dependency of a different project: `npm i <path to the tarball>`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 ?

Why pack ? npm link does not work in this case ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The commands are similar, but I think npm pack is more accurate because it creates an output matching what is uploaded npm.

For example, this config in the package.json tells npm what files to include in the tarball. Say someone created a new directory, but did not update the config. I suspect a local symlink would provide access to the new directory, but when installing from npm, the directory would be missing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok.

I just know that personally, I would hate to work with that flow and would not do as described here :D

Seems like a hassle for "maybe it's going to be more accurate".

1. Build the headless project: `npm run build`.
2. Create a tarball: `npm pack`.
3. Install the tarball as a dependency of a different project: `npm i <path to the tarball>`.
4. Import an export from your sub-package: `import {...} from '@coveo/headless/pkg/<sub-package>'`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway we can do it without the /pkg/ in there ? it's kind of useless info, since it's always going to be there for all sub packages

ie:

import { buildCaseDeflection } from '@coveo/headless/case-assist

Copy link
Contributor Author

@samisayegh samisayegh Apr 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be possible, but with one draw-back: the case-assist directory holding the package.json file needs to be at the root level.

My concern was if headless has n packages, then the root level will become cluttered:

dist/
src/
package1/
package2/
package3/
...

By grouping the sub-packages under a pkg dir, the root is more tidy. Personally, I prefer the shorter path same as you, but I did this as a compromise.

I will check if it is possible to specify a base-path when creating the tarball, but assuming it is not, what do you think between adding the sub-packages to the root vs. grouping them under a dir?

Copy link
Contributor Author

@samisayegh samisayegh Apr 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updates:

Node 12.7 added support for an exports field to allow mapping one path to another.

However, this does not yet work inside typescript projects. Support is expected as part of TS 4.3 due next month, but it is still not working on the beta.

Maybe we could start with top-level directories, and refactor once support is available. This would provide our ideal api, and avoid a breaking change.

I will look further tonight and make the decision tomorrow,

{
input: 'src/index.ts',
output: [
buildUmdOutput('dist/browser', 'CoveoHeadless'),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have any generated documentation that lists the packages and their content?
If yes, where is it?
If not, is that something we plan on providing in the short term?

Just trying to think how customers will find out whether to use CoveoHeadless or CoveoHeadlessCaseAssist.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation does not display the new case-assist module at the moment, but it's something we can address in the short-term. We would add a section on how to consume headless via CDN and can include the name of the injected global.

@@ -15,7 +15,7 @@ declare global {
initialized: boolean;
}[];
config: HeadlessConfigurationOptions;
engine: HeadlessEngine;
engine: HeadlessTypes.HeadlessEngine;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 Maybe I'm just confused, but will that work when passing an engine created through a sub-package? I know that both engines will use the same HeadlessEngine class, but since engines are exposed from two different packages, they will be two different types, no?

Copy link
Contributor Author

@samisayegh samisayegh Apr 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment, there is only one engine class so the type will be the same. I'm not sure if separate types are needed just yet. I will investigate further while looking into how to pass different api clients to different engine instances.

@samisayegh samisayegh merged commit 257001d into master Apr 23, 2021
@samisayegh samisayegh deleted the KIT-605 branch April 23, 2021 13:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants