Task automation with ssb-scripts

[davegomez]

ssb-scripts

Create a JavaScript application or series of scripts bundled in a package that allows us to perform and automate common tasks across all the SSB applications.

Rationale

Keeping a consistent code style, linting rules, and toolchain selection is a challenging goal to achieve, and, in most cases, you could say impossible.

Having an independent package controlling all these elements will allow us to perform all these operations without adding extra work on the package developers and maintainers.

Rules and automation

The following is a list of the tools I consider we can use in all the SSB packages to keep a consistent feel in the code style and automate tasks like CI testing.

We can add more if we consider it necessary.

• Linting with ESLint
• Code formatting with Prettier
• Unit testing with Tape
• Package bootstrapping (optional)

How

ssb-scripts will add/replace some of the host’s package.log scripts, allowing the developer to run the tools directly from the host package.

	...
	"scripts": {
		"lint": "ssb-scripts --lint"
	},
	...

Inspiration

We can use a similar approach to the one used in React Scripts.

ToDo

• Create package and add the repository to ssb-js.

[staltz]

I think this could be good, while I still see how it could be done differently (e.g. by defaulting to popular code styles such as default Prettier). If this is created, though, I recommend it being called ssb-repo-scripts, just to reserve the name ssb-scripts for something creative in the SSB community.

[davegomez]

@staltz this won't necessarily modify the tool defaults but, for example, offers functionality to run the scripts as a git hook to format the code before committing or CI validations.

[christianbundy]

Good idea! Have you seen this? https://github.com/christianbundy/common-good

(It's the 'reasonable default' module for Oasis, which I've very much enjoyed using.)

I think the biggest hurdle: how do we want to deal with code style PRs? I've been hesitant to open one because I don't want to have The Big Code Style Argument, but I'd really like to have some consistent code style in each project. I'd be happier if we had consistent code style in all of the projects, but I'm not sure how popular that idea would be.

Btw, I was recently converted from Standard to Prettier after noticing:

• Prettier is much more popular.
• Prettier handles way more languages (including Markdown!).
• As much as I enjoyed working semicolon-free, it's nice that beginners can add/remove lines from the codebase without having to worry about automatic semicolon insertion. This has even saved me a few times too!

[christianbundy]

I think the steps for this would be:

• Determine whether SSB-JS maintainers want shared rules for code style. (I'd love this.)
• Determine which code style tools should be used.
• Apply the selected code style to all of the appropriate projects.
• Make/choose a tool that can be shared between projects to enforce our tooling combination.

[davegomez]

@christianbundy the formatting can be done with Prettier in a pre-commit hook, nor the developer or maintainer have to worry about this.

ESLint can be used to prevent code with styling errors to be pushed or merged using pre-commit hooks and GitHub actions.

All of these processes can be automated.

[christianbundy]

Yep! I think we agree, I've used both ESLint and Prettier in a pre-commit hook (managed via Husky).

Did you see the first comment I published? I'm very interested in having a tool like this, I just want to make sure that we're discussing the problem with maintainers before building/deploying a solution.

This is probably useful context for why I'm hesitant to touch anything: ssbc/ssb-server#591

[staltz]

I agree on using either Standard or Prettier, I don't care much which one, but I fully agree we should have something that applies automatically.

This is probably useful context for why I'm hesitant to touch anything: ssbc/ssb-server#591

Can also be quite non-controversial to apply Standard: ssbc/secret-stack#53

[arj03]

I don't have any opinions about the specific linters and what not. But I want to add that by doing this, we are avoiding the ssb-server situation up front so I'm much in favor of figuring out something and using that.