npm run start:dev lists @types typescript issues

[anyproto]

npm run start:dev lists @types typescript issues

[ra3orblade]

Seems that your typescript version is incorrect.

[negue]

I always thought during these compile steps it would use the locally typescript version that is set in the package.json, which is ^3.9.7 I checked in the node_modules/typescript Folder and the installed one is "version": "3.9.10", so still in the same range.

Shouldn't be this installed local version be used inside the webpack build step?

Just checked my globally installed tsc - it was 4.1.3 updated that one to the newest - but its the same issue.
Or do I need to downgrade my global tsc to let it compile ?

[negue]

Installing typescript 3.9.7 globally also results in the same error - so neither an upgrade/downgrade globally helped

[negue]

After countless reinstalls of everything, I tried the crazy idea to just install the packages using npm ci install npm install and those TypeScript "issues" (since the d.ts files looked good) are GONE! 🎉

I assume that all packages are not pinned (to the exact version) the npm install wanted to be smart and install the updated version of the rules ^ and I guess some sub module of a sub module broke it completely.

If you want I could create a PR to pin those.

---

Then there is also an issue with the ./update.sh script - it loads the anytypeHelper binary but does not add it to the dist folder.

After moving the helper to dist the code transpiled and the electron shell opened.

---

After trying the Join Button I got this error

ERROR
obj.getNetworkid is not a function
TypeError: obj.getNetworkid is not a function
    at Object.AccountInfo (http://localhost:8080/main.js?0.43440902263090764:517268:32)
    at Object.Account (http://localhost:8080/main.js?0.43440902263090764:517253:51)
    at Module.AccountCreate (http://localhost:8080/main.js?0.43440902263090764:517945:63)
    at http://localhost:8080/main.js?0.43440902263090764:517101:75
    at Array.<anonymous> (http://localhost:8080/main.js?0.43440902263090764:281904:368)
    at Lc (http://localhost:8080/main.js?0.43440902263090764:281897:349)
    at qc.<anonymous> (http://localhost:8080/main.js?0.43440902263090764:281895:302)
    at Jb (http://localhost:8080/main.js?0.43440902263090764:281873:182)
    at O (http://localhost:8080/main.js?0.43440902263090764:281872:614)
    at Ac (http://localhost:8080/main.js?0.43440902263090764:281886:68)
    at __webpack_modules__../node_modules/grpc-web/index.js.n.W (http://localhost:8080/main.js?0.43440902263090764:281884:252)
    at __webpack_modules__../node_modules/grpc-web/index.js.n.R (http://localhost:8080/main.js?0.43440902263090764:281884:231)
    at XMLHttpRequest.<anonymous> (http://localhost:8080/main.js?0.43440902263090764:252454:29)

But I'll probably create a different issue for that

Edit: Reverted my Git State to https://github.com/anyproto/anytype-ts/releases/tag/v0.33.3 instead of main branch and the Join Button issue is gone - means this error is in the current main state 😄

[ra3orblade]

Main TS branch could divert from the latest middleware release so using update.sh to build middleware can result in these errors of protocol mismatch, it is recommended to build anytype-heart from sources.

[negue]

Main TS branch could divert from the latest middleware release so using update.sh to build middleware can result in these errors of protocol mismatch, it is recommended to build anytype-heart from sources.

ok! good to know - that would explain the

ERROR
obj.getNetworkid is not a function
TypeError: obj.getNetworkid is not a function

as for

After countless reinstalls of everything, I tried the crazy idea to just install the packages using npm ci install npm install and those TypeScript "issues" (since the d.ts files looked good) are GONE! 🎉

I assume that all packages are not pinned (to the exact version) the npm install wanted to be smart and install the updated version of the rules ^ and I guess some sub module of a sub module broke it completely.

If you want I could create a PR to pin those.

what do you think about pinning the versions? if accepted I'd create a PR for that

[ra3orblade]

Versions are pinned, you use client from current main and middleware from pinned release, this is ok that they can diverge. If you want a stable current version - use main/main branches, we try to keep them compatible and not merge diverged protocol.

[ra3orblade]

Oh sorry, you meant pinning dependencies, idk actually, I didn't experience any problems before, if you are sure what you are doing - why not.

[negue]

Oh sorry, you meant pinning dependencies, idk actually, I didn't experience any problems before, if you are sure what you are doing - why not.

I'll retry it later at weekend on (some) new folders with different commands (normal npm install, npm ci, npm install with the electron like in readme) before I start the PR - just to be sure that it breaks without the dependency pinning on a fresh install - will report the results

[ra3orblade]

Oh sorry, you meant pinning dependencies, idk actually, I didn't experience any problems before, if you are sure what you are doing - why not.

I'll retry it later at weekend on (some) new folders with different commands (normal npm install, npm ci, npm install with the electron like in readme) before I start the PR - just to be sure that it breaks without the dependency pinning on a fresh install - will report the results

ok, thank you

[negue]

Sorry for the late update.

I just checked npm ci and npm install and npm install -D using the latest release tag ... good news on that front - this time I didn't had any of those issues in the first post ... really weird!

I have NO idea how those errors in the first post ( webpack 5.88.2 compiled with 1050 errors in 23526 ms ) came from. 🤷

As for the pinning dependencies, this article sums up the pro's and con's there:
https://the-guild.dev/blog/how-should-you-pin-dependencies-and-why

In case you'd like to have those pinned I'll create for a PR for that.