Truffle Module in Deno

[michael-spengler]

I run most of my applications via https://deno.land/ --> From my perspective it would be cool to have truffle available as deno third party module.

I prepared the skeleton for this: https://deno.land/x/truffle.

If you like it let's move it to your organization.

[gnidan]

This is cool! Are Deno modules only for libraries? Note that Truffle's library interface is kind of not meant for external use (although there might be a use for publishing @truffle/* packages this way)

[michael-spengler]

Hi @gnidan

To ensure I get your question correctly - here my understanding of words :)

Framework: Application Code is called (by Framework)
Library: Application Code calls (library)

---

In deno the reuse is no longer bound to libraries but can be as specific as e.g. here:
https://deno.land/x/[email protected]#distance-calculator (just importing e.g. a class via https...)

---

You can run e.g. this on a console / terminal after installing deno to play around:

deno run --allow-net https://deno.land/x/distancecalculator/test-it.ts

---

I'm also wandering what would be the smartest way to provide truffle's features in this fancy new world.

Whether it is via truffle being a framework or whether exposed by single methods like in the current draft seems to me less important than the fact that it needs to be implemented in TypeScript (if I get things correctly).

My feeling is that a strong simplification can come along with this.

[gnidan]

Ah @michael-spengler, what I mean by library is just "something with a JS interface". Truffle doesn't really provide a JS interface, it provides a CLI interface. There are individual packages in the monorepo that do provide JS library interfaces, but the main top-level entrypoints to Truffle itself (e.g. truffle test, truffle migrate) are not designed for use inside JS (for instance, they print colorized console output instead of returning JS values)

You might be thinking along different lines than I am, though, so would love to hear more of your thoughts!

Whether it is via truffle being a framework or whether exposed by single methods like in the current draft seems to me less important than the fact that it needs to be implemented in TypeScript (if I get things correctly).

If TS is required then this will certainly have to wait a long time - we've been converting things to TS here and there, but we're nowhere near close to having all of Truffle written in TS, and probably won't be done with that for years.

My feeling is that a strong simplification can come along with this.

You're probably right, but sounds like a challenge to implement :)

[gnidan]

Oh I should note: regardless of these unknowns, thanks for offering us the truffle namespace! I think getting this Deno stuff hooked up for Truffle is a nice goal!

[michael-spengler]

Oh I should note: regardless of these unknowns, thanks for offering us the truffle namespace! I think getting this Deno stuff hooked up for Truffle is a nice goal!

Of course @gnidan - I just invited you as collaborator to the repository behind https://deno.land/x/truffle - so you can move the ownership of the repo. Of course it would also be an honor to me if you invited me to the trufflesuite :)

[michael-spengler]

@gnidan: I got some good connections to the https://gitcoin.co/ ecosystem - I would like to encourage some fellows to fund the provisioning of truffle / web3 etc. as deno modules.

Which amount of ETH would you consider a fair incentive e.g. to provide a reliable Truffle Deno Module?

[michael-spengler]

Ah @michael-spengler, what I mean by library is just "something with a JS interface". Truffle doesn't really provide a JS interface, it provides a CLI interface. There are individual packages in the monorepo that do provide JS library interfaces, but the main top-level entrypoints to Truffle itself (e.g. truffle test, truffle migrate) are not designed for use inside JS (for instance, they print colorized console output instead of returning JS values)

You might be thinking along different lines than I am, though, so would love to hear more of your thoughts!

Whether it is via truffle being a framework or whether exposed by single methods like in the current draft seems to me less important than the fact that it needs to be implemented in TypeScript (if I get things correctly).

If TS is required then this will certainly have to wait a long time - we've been converting things to TS here and there, but we're nowhere near close to having all of Truffle written in TS, and probably won't be done with that for years.

My feeling is that a strong simplification can come along with this.

You're probably right, but sounds like a challenge to implement :)

Thanks for these inputs. Let's see how this evolves. I'm also still getting used to the deno style :) In some sense the console / terminal became a kind of webbrowser with the deno approach - not for pages but for code --> and somehow in this sense any deno module can be seen as a (remote) cli - leveraging this along the way could be a cool thing...

[michael-spengler]

@gnidan: I got some good connections to the https://gitcoin.co/ ecosystem - I would like to encourage some fellows to fund the provisioning of truffle / web3 etc. as deno modules.

Which amount of ETH would you consider a fair incentive e.g. to provide a reliable Truffle Deno Module?

Perhaps we can also somehow break it down to specific features - coming up with a step by step approach. Really feel free to put some fair "Ether Price Tags" on it.

[michael-spengler]

Perhaps helpful: https://medium.com/samsung-internet-dev/using-node-modules-in-deno-2885600ed7a9

[gnidan]

Hey @michael-spengler sorry to lose track of this one. I'll get back to your thoughts in a few days!

[michael-spengler]

Some more info which might be helpful along this journey: michael-spengler/wwi18seac#8 (comment)

Plus the link to the Deno community in Discord: https://discord.gg/deno Feel free to join.

[dance-planner]

Regarding CLI Support:
https://deno.land/x/cliffy
https://nest.land/package/cliffy

[gnidan]

I've been thinking about this and I feel like it's very unclear. Maybe we start with individual Truffle packages? There's a lot inside Truffle and I am not keen to jump into redoing the way the CLI works to support Deno.

I think the next step here might be to call this "needs requirements". This issue itself seems like a very large undertaking, so perhaps we can split it up into smaller, more digestible efforts?

[playerx]

It would be great to have similar tooling for testing like clarinet has. example of usage:
https://github.com/playerx/stx-smart-contract/blob/master/tests/ezeki_test.ts