Monorepo

[crutchcorn]

This PR merges in all of node-plop (and preserves the history for archival purposes) and makes this repository contain 100% of the code required for plop to run with two packages present.

Closes plopjs/node-plop#211

Checklist:

• Documentation (root README)
• Tests
• Linting/formatting
• CI/CD
• Update package.json links to reflect directory structure (so that when someone clicks on "repo" it goes to the subrepo
• Commit message enforcement
• Changelog generation
• Publishing guide (CONTRIBUTING.md)

Post-merge checklist:

• Archive node-plop repo to avoid duplicate issues in the future
  • Blank out README, direct to monorepo subpath
• Migrate open node-plop issues to this repo
• Mention migration to all node-plop PRs
• Publish minor versions of plop and node-plop to update NPM website links
• Add a PR to mention PlopJS in changesets

[crutchcorn]

OK, I think we're just about ready to merge this!

@amwmedia @evelynhathaway can you take a look at this and let me know if there's anything obvious missing here and what you think of the whole process?

Namely, a few things:

1. New CHANGELOG.md files will now live in packages/{packageName}/CHANGELOG.md after this merge and initial release
2. I don't intend on backfilling the respective CHANGELOG.md files. They'll simply start after plop@3.0.6 and node-plop@0.30.1 (our next patch versions)
3. New GH tags will be created automatically with the changesets publish and will include the package name. EG: plop@3.0.6 and new tags will follow the same format. While I don't plan on updating the tags (this would break a lot of links), I would like to update the plop GitHub release names since 3.0 to names like plop@3.0.0 or whatnot.
4. I'd like to bump node-plop to 1.0.0 as part of this migration? I think it would help reduce a lot of confusion with node-plop in particular

@amwmedia one question in particular for you:

5. How does the plopjs.com site generation work? Do I need to change anything here to make that process work still?

[crutchcorn]

This will 100% break when we release a, say, v2 of node-plop.

We either need to lock this to:

Suggested change

	"node-plop": "*",
	"node-plop": "~0.30.0",

Or, if we decide to bump to 1.0.0, like I'm hoping we can:

Suggested change

	"node-plop": "*",
	"node-plop": "^1.0.0",

[evelynhathaway]

Agreed. Also, caret works for both so we can use it to select nonbreaking changes either way.

https://docs.npmjs.com/cli/v6/using-npm/semver#caret-ranges-123-025-004

[crutchcorn]

Up for suggestions about how to communicate this better. This should only ever be seen by contributors on their machine or on GitHub.com.

Otherwise, our prepublishOnly.js script should replace this with the README.md that matches our existing README.md.

The reason for two README.md files is so that we can still display a proper documented README for newcomers to the repo, while still providing a README for contributors pointing them to the right place

[evelynhathaway]

To avoid the need for the switch back and forth, could a git hook that syncs these help?

Or commit to having two copies of some of the information and work on making the main readme talk about all of the projects? I kinda like having a separation between the monorepo readme and the published ones. A markdown comment reminding folks to make their changes in two locations.

[crutchcorn]

I'm actually not a huge fan of having two different READMEs. The contributors will forget, we'll forget, then we have to manually squash things, it's kinda a mess IMO.

While I usually like having a separate monorepo README and published one, I think it makes sense here. Open for alternative READMEs after this, but I think this is probably the right move for now

[evelynhathaway]

I don't see where ESLint is using this.

Do you use either of these?

https://github.com/typescript-eslint/tslint-to-eslint-config

https://github.com/typescript-eslint/typescript-eslint

[crutchcorn]

Yeah, we use typescript-eslint for TS files itself

[evelynhathaway]

Could you point to where it's used? My original comment was that I don't think it is currently being used.

[evelynhathaway]

Agreed. Also, caret works for both so we can use it to select nonbreaking changes either way.

https://docs.npmjs.com/cli/v6/using-npm/semver#caret-ranges-123-025-004

[evelynhathaway]

To avoid the need for the switch back and forth, could a git hook that syncs these help?

Or commit to having two copies of some of the information and work on making the main readme talk about all of the projects? I kinda like having a separation between the monorepo readme and the published ones. A markdown comment reminding folks to make their changes in two locations.

[amwmedia]

For the plopjs.com site generator. You can see the file that does the work here.

It's essentially pulling the MD file from the repo and replacing the top part of the file with some front-matter for the static page generator. So long as that file didn't move (which I don't think it did), the site generation should be fine.