CLI could initialize the scaffolding for releasing React libs

[grgur]

Description

Releasing open source React components requires heavy scaffolding. Once we are done with tests, CI, and examples for react-idle, we could use that setup for other similar projects

React Idle setup is somewhat opinionated but to a reasonable degree. For instance:

• Flow is set up. Not all projects require flow, but having type safety in an open source project is extremely helpful
• code formatting with eslint and prettier should stay there, but tweaks are possible
• rollup is used over webpack, which may introduce a learning curve. Still, rollup has certain advantages for libraries, which was also heavily researched by React team
• testing suite may prove to be too specific, but we'll see that it's reasonable enough
• we like to work with different CIs and will need to pick one

This may require a separate repo. It would be interesting to create something like create-react-app so it can be maintained from one place

[mitchellsimoens]

Flow is set up. Not all projects require flow, but having type safety in an open source project is extremely helpful
code formatting with eslint and prettier should stay there, but tweaks are possible

100% agree, I think things should be setup with Flow, eslint and such as it's a good thing to recommend. Tools like this should be the minimum in projects right now.

Not to complicate things more than they need to be. One thing I don't like about create-react-app is one size doesn't fit all. Now I think it makes sense for facebook to only have one thing but for a 3rd party it'd be great to have a great default but then allow other "template" to be used. So we could have a redux as the default but we could have a mobx one you can tell the cli to init. This could also be for different CIs, testing suites and bundlers and allow future things while still keeping old things that we know are great and work.

What I imagine for that is to have a separate repo, have it be a monorepo maybe and the name of the directory is the name of the template so you could --init mobx-template and that would go to the monorepo and use the mobx-template directory as the template.

You can always take my "grand ideas" with a grain of salt too, no hurt feelings from me :)

[mschwartz]

I'm thinking maybe we have a modus-cli.json file that describes the possible setups.

The json file would have key like "default", or "ionic", or "react", and so on.

The values would be an array of objects, each defining subdirectories in various repos (like guidelines) to fetch and which to ignore in those, as well as CLI like commands to execute (such as "download and rename README.sample.md to README.md if it doesn't exist").

So the command would be something like:

modus-cli (does default/guidlines)
modus-cli (guidelines)
modus-cli ionic (does ionic repo stuff)
modus-cli react (does react repo stuff)

Thoughts?

[mschwartz]

I should mention that I really don't like JSON configuration files... I'd much rather we use a .js file that just exports the same object that would be expressed in JSON.

The reason? You can comment a .js file. And comment out lines.

[mitchellsimoens]

The reason? You can comment a .js file. And comment out lines.

And programmatically return an object (think diff envs). Even if it's just module.exports = {...} or module.exports = () => {...}

[grgur]

I agree with .js

Also, IMO, I would love to see

• modus init react for a bare-bone react project. We have tons of experience and great solutions here
• modus init react-lib for React libraries

[mschwartz]

^^^ In addition to modus guidelines ?

Or we could do modus init guidelines and make a "radical" change :)

[grgur]

yeah. that's why I prefixed with modus init.

[mschwartz]

This is a fairly significant refactoring of the program. I'm up for it, but I want to make it known.

init and update in the examples below would be plugins still, I guess.

modus-cli init guidelines

and

modus-cli update

Are there any other "commands" we want aside from init and update?

We could do some git stuff, to make things handy. Like:

• modus-cli git init repo which would init a directory as a repo, and do initial push to it.
• modus-cli git new branch which checks for files in current branch that aren't committed, switches to master, does a git checkout -b, etc.

etc.

[mschwartz]

modus-cli add eslint
modus-cli add prettier (installs eslint, prettier, and sets configuration files)
etc.

[mschwartz]

Worked on this a bunch, but I ultimately came down to one question.

Why not just git fork a template we make vs. using this tool?

[grgur]

Here's how I see cli over fork:

1. there's no history (both pro and con)
2. it's clean for projects that wouldn't allow forking
3. it's more difficult or impossible to update from the central repository, but it's unlikely that clients will expect that. Also projects will be customized heavily to make sense of any updates

Anything else?

[mschwartz]

I'm looking at "opinionated" repos. You need different opinions for NodeJS, for React, for React+Redux, React+Mobx, React+anything+flow, Typescript, angular, ionic, C, C++, shell scripts, AdonisJS, and so on. Using webpack, babel, eslint and/or prettify, tslint, etc. The complexity of incrementally adding .*rc files, editing package.json (if there is one), etc., becomes ridiculous.

To get rid of history after a fork or clone, rm -rf .git.

This tool is fine at downloading/overwriting/backup copy of files in a branch - it can be ANY repo, any branch. So I you want to update files in a non-repo from a repo, not a problem. That is, if you fork super-duper-react-template repo, and get rid of .git, you can still modus-cli update --repo org/super-duper-react-template and get any new/updated files.

However, if you are syncing with an upstream repo (e.g. fork), you can simply do git merge upstream/master.

At some point, we're duplicating (without being as complete) what git already does. See?

[mschwartz]

I'm speaking to these comments (that were mine!):

[mschwartz]

Blocker nodegit/nodegit#1490