Trim down sensible defaults on algokit templates

[aorumbayev]

Proposal

1. .copier-answers.yml x3 -> do we really need to show them?

• • - research on options behind hiding the copier answers inside .algokit file
• • - to be checked upon resolution of the item

3. envs x8 -> there are 6 env files (sc), and 2 in the frontend, could we slim them down?

• • - agree on sensible defaults to trim down the .env files, whether its removing certain network/generic .env files OR opting for extra feature in bootstrap that auto deletes the .env.template files

4. license -> shall we nuke it? I reckon that 99% of users will do it visually by github once/if it's time to opensource the repo

• • - to be checked after license is removed from all templates

5. .editor-config x3

• • - research on options around keeping a single editorconfig applied globally to all child subprojects
• • - to be checked upon resolution of the item

7. .gitattributes x3 -> are they useful?

• • - research on options around keeping a single gitattributes applied globally to all child subprojects
• • - to be checked upon resolution of the item

9. .devcontainer.json -> should we put it behind a generator? algokit generate devcontainer

• • - to be checked after devcontainer file is moved into an actionable generator supplied as part of the baseline template

11. tsconfig and tsconfig.node -> do they need to be separate files?

• • - research on options to combine into one tsconfig file

[aorumbayev]

@Loedn @robdmoore open questions:

1. Do we want to:

• • a) Cut down .env file from sc contracts folder and refer to .env.localnet, .env.localnet.template, .env.testnet and .env.testnet.template files to be created by default after full init?
• • b) Expand bootstrap to auto delete .env.template files after it creates a base .env from that template?
• • c) Ignore a,b and instead have a generic generator thats invocable from the root of individual projects (would require 1 unique smart contract specific env generator as it needs to be aware of deploy conventions) and generic generator on frontend OR we only introduce that generator on smart contracts projects given that its a single .env and .env.template on frontend that is fairly conventional setup for frontend frameworks already

[robdmoore]

Single gitattributes in git root will work, no need to research that.

[robdmoore]

(but if you do single project mode rather than workspace you should keep the gitattributes)

[robdmoore]

I feel like when deploying to testnet or mainnet we can have default values that get used if no .env.{env} is present. Then they don't need to be there by default and we can include a generator that spits out those files with the default values populated so you can take control and add other values / change the defaults / etc.

[aorumbayev]

cc @SilentRhetoric @Loedn @robdmoore, above reference PRs are addressing the issue, hence closing the item.

Final set of changes included:

1. Algokit cli now enforces defaults for algokit project deploy mainnet|localnet|tesnet, removing the need for .env.template files in contract repos (beaker and python are updated, however for tealscript i'll cc @joe-p, in case you'd like to follow the convention on tealscript repo, simply remove the .env files if you got any unless there are special .env files not specific to network configs)
2. Python, Beaker, fullstack, react templates now dump copier answers file under .algokit project. CLI is updated to properly search for answers in .algokit folder to maintain ability to do copier upgrade and pre-fill answers to generators when executing them
3. Python and Beaker repos now contain env-file generator that generates generic or network specific files for smart contract based algokit projects
4. Base template now includes devcontainer generator while removing the file by default (if user needs one it can be generated via algokit generate devcontainer generator command)
5. React template removes LICENSE.md file as templates should not enforce any licensing
6. Standalone templates (puya, react, beaker) keep gitattributes files in no workspace mode, in workspace mode neither of standalone templates will contain any .gitattributes file (will still keep the gitattributes at the workspace root in such cases). CC @joe-p if you are using gitattributes in tealscript repo you can parametrize the file via is_workspace answer that is passed by cli.