search

trufflesuite / truffle

:warning: The Truffle Suite is being sunset. For information on ongoing support, migration options and FAQs, visit the Consensys blog. Thank you for all the support over the years.
https://consensys.io/blog/consensys-announces-the-sunset-of-truffle-and-ganache-and-new-hardhat?utm_source=github&utm_medium=referral&utm_campaign=2023_Sep_truffle-sunset-2023_announcement_
MIT License
14.02k stars 2.31k forks source link

truffle develop mistakes test variable as running truffle test #5894

Open emilyJLin95 opened 1 year ago

emilyJLin95 commented 1 year ago

when reassigning a variable called test in the console, truffle mistakenly runs truffle test

cds-amal commented 1 year ago

Nice find @emilyJLin95. This would fail with any expression that assigns to a variable that matches an allowed truffle command. So, for example: build = MetaCoin.deployed() ... would try to kick off a build. :facepalm: Oh well. The least we can do is add logic to consider an assignment statement, whose target (LHS) matches an allowed truffle command.

haltman-at commented 1 year ago

I don't think just handling assignment statements would work very well. What happens if I do test = await TestContract.deployed(); followed by test . run ( )? :-/ I don't know if it makes sense to handle it without some more general way...

But, I think that more general way might exist! What if we used vm.compileFunction()? I think we could use vm.compileFunction as a way to check if the input is valid JS, in that it'll throw an exception if it isn't. :)

...of course, even that doesn't totally solve the problem, because you could have it be the case that a given input is valid JS, but also valid as a (reasonable) Truffle command, and then we're left figuring out what to do in that case. E.g., if someone just types test, they could want to print out the value of their variable test, or they could want to run truffle test; I think we kind of have to assume the latter in that case.

So, there's definitely some tricky logic to be figured out here in order to get something that is correct most of the time. Maybe something like:

  1. If it's valid JS, and also not a single Truffle command on its own, treat as JS
  2. If it's a single Truffle command on its own, or is a Truffle command in a way that is not valid JS, treat as a Truffle command
  3. If neither (1) nor (2) hold, produce an error that assumes it was meant to be JS

...this might require a call from @gnidan, IDK.

cds-amal commented 1 year ago

Yes, the REPL can't easily disambiguate a truffle command and a valid JavaScript expression here. I think the best solution is to treat JavaScript like JavaScript and introduce a DSL to invoke truffle commands, like :test, :truffle_cmd.

gnidan commented 1 year ago
  1. If it's valid JS, and also not a single Truffle command on its own, treat as JS
  2. If it's a single Truffle command on its own, or is a Truffle command in a way that is not valid JS, treat as a Truffle command
  3. If neither (1) nor (2) hold, produce an error that assumes it was meant to be JS

I concur that this is probably the right path, with one added point: if you assign to an identifier that clobbers a Truffle command, then subsequently that identifier should be treated as the variable and not treated as a command invocation (so test = ... followed by test should show the value of test)

We'll of course need truffle test to continue working in this case, so you can still run the command... and we might even want syntactic sugar (@cds-amal you suggested :test to mean explicitly "run the test command", and I like this as an additional thing, not as a global replacement to the way we run commands)