catdad/dev-init

:sailboat: initialize new projects with Kiril-approved settings

dev-init

This project will get you started and automate a whole bunch of little things you need to do to every new project in order to work sanely with a team or accept contributions from other members of the open-source community. Since there are so many little steps, they take time and you always end up forgetting something and needing to make a bunch of tweaks later on. You should skip all of that, and just use this module to get up and running quickly.

Sweet, how do I install it?

I appreciate your enthusiasm.

npm install -g dev-init

How do I use it?

Easy:

mkdir my-cool-lib
cd my-cool-lib
dev-init

So what happens?

git init

The regular git init command is run for the module, to create all the necessary git bits.

.gitignore

A default .gitignore file is used, suitable for NodeJS module and application development on macOS, Windows, and Linux. If you already have one of these files (perhaps you want to run this module on an existing repo), the values from this list will be merged into your existing file.

.gitattributes

A default .gitattributes file is used, to standardize file checkouts across macOS, Windows, and Linux. This will ensure things like linting will never be broken on operating systems that you might not be using, but other members on your team are. If this file already exists, this will be skipped by default.

.brackets.json

Kiril approves of Brackets. So a configuration file is created to correctly set up Brackets. If you already have this file, the settings will be merged into your existing file.

There is an option here to select your preferred linter:

dev-init --linter ESLint

You can define as many linters as you would like to use:

dev-init --linter ESLint --linter JSHint --linter JSCS

You can also configure the number of spaces to use for indentation, although I strongly encourage you to stick to 4.

dev-init --spaces 2

.editorconfig

Kiril also approves of other IDEs. An .editorconfig file will be created to configure a whole plethora of other IDEs. If your favorite IDE does not support it natively, there is probably a plugin for it. If you already have this file, the settings will be merged into your existing file.

Like with .brackets.json, spaces are configurable.

dev-init --spaces 2

README.md

An empty readme file will be created, to get you started and remind you that writing a readme is important. If a README already exists, this will be skipped by default.

Whoa, merging files! Is that safe?

I'd like to think it is. I did a great job writing it. And, just so you know, if there is a merge error, your existing files will be safe. However, if you don't trust me, there is a flag for that.

dev-init --safe

With this flag, existing files will be left untouched.

You mentioned something about some files being skipped?

Yeah. Not all files can be merged at this time. For those, I will respect your existing settings and leave them alone (until I can figure out a good way to merge them, anyway).

If you do want to use the files from this module, however, there is a flag for that too:

dev-init --force

This flag will replace all of the skipped files with the ones generated by this module. Files that are usually merged will still be merged.

What if I want to run only some of the tasks?

Well, this is your lucky day, because you have options:

• dev-init --include list of tasks

  You can use the --include flag, followed by a space-separated list of task names, as a whitelist for which tasks to run.

• dev-init --exclude list of tasks

  You can use the --exclude flag, followed by a space-separated list of task names, as a blacklist for tasks to skip.

You can also combine these, but they apply on top of one another (i.e. the exclude list will exclude tasks that were explicitly included in the include list).

• dev-init select

  You can use the select command to enter an interactrive menu, where you can visually select the tasks to run.

But what are the task names?

That's easy too:

dev-init list

And if that is too much typing:

dev-init ls

I don't like your settings.

That's not really a question, but it is also okay. Not everyone has to make the correct choices. You can still use this project though, to configure and enforce the settings you do prefer. Feel free to clone it and make all the changes you would like to the files in the fixtures folder.

You can set it up in your dev environment as such:

git clone [email protected]:catdad/dev-init.git
cd dev-init
npm install
npm link

Now you can make changes and use the dev-init cli command with your local version.

License

ISC

dev-init's Issues

don't overwrite existing files

consider not trimming whitespace for markdown files

[*.md]
trim_trailing_whitespace = false

I don't remember the argument for this, but I remember it sounded good at the time.

better way to get template files

document cli flags

• --force
• --safe

`dev-init select` works terribly in bash on Windows

And by works terribly, I mean not at all. It does not clear the terminal, the menu shows up but you cannot navigate it, when you exit, the whole screen is the background color of the menu, etc.

add ability to run only specific tasks from the list

• --include and --exclude flags?
• an interactive selection menu?
• other ideas?

add flag to force overwrite files that are usually merged

Maybe something explicit like a --force-overwrite. I don't want to use the original --force for this.

run "npm init" to get a package file

If you invoke it with -f, --force, -y, or --yes, it will use only defaults and not prompt you for any options.

https://docs.npmjs.com/cli/init

replace __base with rootrequire

__base is ugly and was kind of a bad idea.

install mocha, chai, istanbul for node/npm projects

add sh to .gitattributes

figure out how to merge .gitattributes

merge-file should catch merge errors and inform the end user

The reasons we would not be able to merge is that the existing file has something wrong with it. While we do not want to overwrite that file -- we should assume the user created it with purpose -- the file cannot be used as intended and the user should be made aware that the file is wrong, instead of silently avoiding the merge.

support for Jenkinsfile syntax highlighting in brackets.json file

Is generic enough?

configurable spaces for indentation for brackets and editorconfig files

add --safe option that will not attempt to merge files

add .mjs extension to brackets.json

add .mjs to gitattributes template

.npmignore file

Add .npmignore file. This way, we can add extra stuff that belongs in git but does not belong in the NPM published package, like all the dotfiles.

add .nyc_output/ to gitignore template

This is what nyc uses for temp storage of coverage data, and should be ignored by default to support usage of nyc instead of istanbul.