Skip to content

Conversation

@hudlow
Copy link

@hudlow hudlow commented Nov 13, 2025

No description provided.

Comment on lines 15 to 25
export { equals } from "./equals.js";
export { createDuration } from "./duration.js";
export { getMsgDesc, setEvalContext } from "./eval.js";
export type { CelList } from "./list.js";
export type { CelMap } from "./map.js";
export { Namespace } from "./namespace.js";
export { parse } from "./parser.js";
export { createRegistryWithWKT } from "./registry.js";
export { matchesString } from "./std/logic.js";
export type { CelValueTuple } from "./type.js";
export type { CelUint } from "./uint.js";
Copy link
Author

Choose a reason for hiding this comment

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

I suspect we'll want to move a lot of these to the primary export, but I did it this way so we could make purposeful decisions about it.

The biggest "gotcha" here might be the parse function since the main export already has a different parse function — we can probably just adapt the tests to use it.

Comment on lines 43 to 45
"./internal": {
"import": "./dist/esm/internal.js",
"require": "./dist/cjs/internal.js"
Copy link
Member

Choose a reason for hiding this comment

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

This will mean others will also be able to access them as well. Can't we detect the usage of node types using linter for the non test files?

Copy link
Member

@srikrsna-buf srikrsna-buf left a comment

Choose a reason for hiding this comment

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

I think we can split this into 2 PRs. The first is to remove the one node dependency that snuck in today (TextEncoder and TextDecoder). The other one to avoid such things in the future. First one should be pretty straightforward because we do this in other projects as well.

Having the tests (especially unit tests) colocated is very advantageous. IDEs can recognize them, debugging is easier because we are dealing with TS e2e. If we split into a separate package this becomes tougher as the first package has to rebuild and tests depend on the transpiled version. It is not the end of the world but definitely inconvenient. I am not sure if this is worth the tradeoff.

@hudlow
Copy link
Author

hudlow commented Dec 4, 2025

@srikrsna-buf Per feedback, pared this down to just the fix without the updates that would have caught the problem.

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