这是indexloc提供的服务,不要输入任何密码
Skip to content
This repository was archived by the owner on Jul 10, 2025. It is now read-only.

Conversation

@akim-bow
Copy link
Contributor

No description provided.

@linear
Copy link

linear bot commented Dec 13, 2023

return await gatherImportsFromArborist(arb);
}

export async function gatherImportsFromArborist(
Copy link
Contributor

Choose a reason for hiding this comment

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

what is the reason to have this as a separate function? do we plan on using it separately from the gatherImportsFromNpm function?

Copy link
Contributor Author

@akim-bow akim-bow Dec 14, 2023

Choose a reason for hiding this comment

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

Agree. Probably we need a former function only

Comment on lines 23 to 25
const arb = new Arborist({ path });

return await gatherImportsFromArborist(arb);
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
const arb = new Arborist({ path });
return await gatherImportsFromArborist(arb);
return gatherImportsFromArborist(new Arborist({ path }));


for (const edge of node.edgesOut.values()) {
// Skip dependencies that are not installed.
if (edge.to === null) {
Copy link
Contributor

Choose a reason for hiding this comment

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

for me it vscode says that edge.to is never null. Is it on practice sometimes null? If so - for me eslint has a warining here because of that

Copy link
Contributor

Choose a reason for hiding this comment

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

As I mentioned in slack, types for arborist are improper. While I was testing this code, I got null in edge.to. As far as I understand, this will be null for not installed deps (for some reason). @akim-bow please try to test this function on some big project with a lot of deps.

item.tag === "labeledProduct" ? Object.values(item.fields) : item.items;

if (args.length === 1) {
if ("0" in args) {
Copy link
Contributor

Choose a reason for hiding this comment

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

these are actually different. Previously you checked the length is exactly equal to one. Now you are checking that first element exists. Does it make sense to still check the the length is exactly === 1. Can it ever be !== 1? If this is something aqua compiler enforces - I would probably check the case when it's not 1 and maybe throw error - this we will get a chance to discover some unexpected bug

the same question to think about is for the same check you are doing bellow

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wil recheck these in other files

Comment on lines 68 to 77
if (!("demoCalc" in functions)) {
throw new Error("Aqua code must contain demoCalc function");
}

const { script } = functions["demoCalc"];

if (!("Calc" in typedServices)) {
throw new Error("Aqua code must contain Calc service");
}

Copy link
Contributor

Choose a reason for hiding this comment

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

both can be asserts, because it's inside test. You can leave it as it currently is as well

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Would prefer to do assert in test


setTimeout(() => {
rejectCallback(err);
rejectCallback(err ?? "Error hasn't been provided");
Copy link
Contributor

Choose a reason for hiding this comment

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

I am currious when that can happen. I think would be a bit weird to see in the console "Error hasn't been provided"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This can happen if someone wrote incorrect air code and hasn't passed any args there.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated to a more lucky description

Copy link
Contributor

Choose a reason for hiding this comment

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

Still I think it's hard to understand for the user what is he supposed to do. If it's most likely a problem with the complier - then the error should say that as well


if (serviceImplValue === undefined) {
throw new Error(
`Expected to have ${schemaKey} in service implementation according to schema`,
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this happen if user didn't implement the service he was supposed to implement? Or when does it happen?

I would prefer a more actionable error. Users wouldn't know what's the schema what's the key and where, especially if they don't use typescript

Comment on lines +127 to 130
def.arrow.codomain.items.length === 1 &&
"0" in def.arrow.codomain.items
? def.arrow.codomain.items[0]
: def.arrow.codomain;
Copy link
Contributor

Choose a reason for hiding this comment

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

Don't you want to extract this pattern to some function? It is repeated at least 3 times

Copy link
Contributor

Choose a reason for hiding this comment

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

probably possible with this

function isArrayWithOneElement<T>(arr: Array<T>): arr is [T] {
  return arr.length === 1 && arr[0] !== undefined;
}

Copy link
Contributor Author

@akim-bow akim-bow Dec 14, 2023

Choose a reason for hiding this comment

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

Will keep it in mind. This PR already bloated too much, i will do this in the next PR.

@@ -0,0 +1 @@
package-lock.json No newline at end of file
Copy link
Contributor

@InversionSpaces InversionSpaces Dec 14, 2023

Choose a reason for hiding this comment

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

Why not storing package-lock.json in git?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure should i keep it or no.
When this file is present and some dependencies changes e.g. someone adds more packages to tests, npm just breaks without meaningful error.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Without this file in git there is a less chance to fight with strange bugs when developing tests

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From the other side this file will keep the tests more persistent, would be easier to track changes. Probably i will keep it, thanks.

Comment on lines 20 to 22
export async function gatherImportsFromNpm(
path: string,
): Promise<Record<string, string[]>> {
Copy link
Contributor

Choose a reason for hiding this comment

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

This does not return imports according to the latest spec.
https://www.notion.so/fluencenetwork/Aqua-Imports-Spec-082d48d2d7184b05a3f47f35b781c843
Type of new imports is Record<string, Record<string, string[] | string>>. Read more in the doc.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah I totally forgot we decided on a different structure. Thanks for the catch.

@InversionSpaces
Copy link
Contributor

A vast part of changes are not related to DXJ-566 in any way as far as I understand. Why do like so...

@shamsartem
Copy link
Contributor

A vast part of changes are not related to DXJ-566 in any way as far as I understand. Why do like so...

Yeah would probably better to do refactoring in a separate PR, would be easier to review. But I support this refactoring in generall, even though I agree this is probably not the best place to do that as part of this PR

Copy link
Contributor

@shamsartem shamsartem left a comment

Choose a reason for hiding this comment

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

nice. thanks

@fluencebot fluencebot mentioned this pull request Dec 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

e2e Run e2e workflow

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants