how does NEAR Protocol recommend local development?

Question

disclosure: I work with NEAR and am currently onboarding

based on the docs (docs.nearprotocol.com) and diving into the nearcore/scripts folder, looks like there are currently 5 ways to start a local node for development and testing (ie. developing DApps, integrating with or contributing to the platform) as well as validating (as part of NEAR Stakewars)

they all have the option of starting a Docker container or compiling and running the code natively

(see repo on GitHub @nearprotocol/nearcore/scripts/start_*)

the two that seem most useful to a DApp developer are

• start_localnet and
• start_testnet

the first launches a node that is totally isolated to local development while the second connects to the NEAR TestNet (via a common list of bootnodes and a telemetry URL)

which of the above does NEAR recommend for local development?

for completeness, here all 5 startup scripts:

• start_localnet
  totally isolated, not related to NEAR TestNet at all (no bootnodes nor telemetry)
• start_testnet
  connected to NEAR TestNet via bootnodes and telemetry. apparently can also reuse existing genesis.json file if found
• start_stakewars
  if you're participating in NEAR Stakewars, this is your startup script
• start_unittest
  used by nearcore, near-bindgen and near-evm
• start_staging_testnet
  used by near-bindgen examples "cross-contract-high-level"

PSA1: near-bindgen has some well documented examples -- if you don't already, just decide now that you want to learn Rust

PSA2: near-evm seems like a proof of concept that lets you run Ethereum Smart Contracts on the NEAR Platform

Answer 1

Normally start_testnet should be enough as it lets developers to deploy and test their contract on testnet, which I assume is what most developers want. However, there are certain cases where start_localnet is preferable. For example, if you want to use a different genesis for whatever reason (One reaons I can see is that if you want to see how much things cost with different config parameters), or if testnet is unstable, or if you want to run customized nearcore code that maybe incompatible with testnet code.