-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(monorepo): use liferay-npm-scripts for formatting #146
Conversation
This resolves disagreements between Prettier and ESLint about how comments should be formatted; eg. Prettier's preference: ```ts export interface X { /** * Yo! */ thing: string; } ``` vs ESLint's preference: ```ts export interface X { /** * Yo! */ thing: string; } ``` by passing everything through liferay-npm-scripts. It provides us a Prettier-like wrapper which abstracts over all this, and effectively runs Prettier + a post-processing pass under the covers. This also means that we'll use the exact same formatting style in this repo as we use in liferay-portal. Closes: #128
Done with `yarn format`.
I didn't originally implement this because we didn't need it, but now that we're using the wrapper in the monorepo we need this for "format:check" to work. Test plan: 1. Add a formatting problem. 2. See `yarn format:check` report the bad file and exit with code 1. 3. Run `yarn format` to fix the problem; see it exit with code 0. 3. Repeat `yarn format:check` and see it exit with code 0.
So that we can get Liferay-specific formatting in this repo as well. This is not a particularly "clean" solution, but nothing in this script is clean... We detect liferay-portal by looking at the directory structure, but we detect the monorepo by looking for a "sentinel" dotfile in the root. We can do this in the monorepo because it is "our" repo, unlike liferay-portal, where many more people work, and adding stuff to the root without good cause would soon lead to overcrowding. There is nothing structural about the repo that I'd want to key off of as an alternative mechanism (because we might move packages around). We could look inside each package.json we see to see if the name is "liferay-frontend-projects", but the existence check implemented here seems cheaper, so I went with that.
Same as the parent commit did for the sibling prettier.js wrapper, this commit teaches the Bash wrapper about this repo too.
Noticed that this wasn't set up while preparing the parent commit.
} | ||
else { | ||
root = getFrontendProjectsRoot(filepath); | ||
|
||
if (root) { | ||
const scripts = path.join( | ||
root, | ||
'projects/npm-tools/packages/npm-scripts' | ||
); | ||
|
||
const wrapper = path.join(scripts, 'src/scripts/prettier.js'); | ||
|
||
if (fs.existsSync(wrapper)) { | ||
dir = scripts; | ||
file = wrapper; | ||
} | ||
} | ||
else { | ||
const extension = require('vscode').extensions.getExtension( | ||
'esbenp.prettier-vscode' | ||
); | ||
|
||
if (extension) { | ||
dir = path.join(extension.extensionPath); | ||
file = path.join(dir, 'node_modules/prettier'); | ||
if (extension) { | ||
dir = path.join(extension.extensionPath); | ||
file = path.join(dir, 'node_modules/prettier'); | ||
} | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LIFERAY_NPM_SCRIPTS="" | ||
LIFERAY_PRETTIER="" | ||
|
||
# Auto-detect a liferay-portal or liferay-frontend-projects checkout. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the different formatting rules in effect now, this structure is a bit better (vertically shorter without being too dense).
As this touches almost everything, we kind of have to get this in quickly (because it will conflict with anything that comes after it), so given this resounding endorsement, the fact that this change is mostly the result of automation, and it's green, I'm going to merge it. |
This is still a bit rough (would like to follow up with a refactor commit), but it implements a basic `--interactive` mode which replaces this flow: npx @liferay/changelog-generator --dry-run # preview changes, decide on release type npx @liferay/changelog-generator --patch # actually generate changes git add -p # stage changes yarn version --patch # do release with this: npx @liferay/changelog-generator --interactive yarn version --patch It's a big ugly inside, but effectively we have a little state machine that goes through this cycle: 1. Run like `--dry-run`, and show a preview of what would be changed. 2. Prompt user for a version number (can be "major" etc or an explicit number). 3. Actually write out changes with the version number in effect. 4. Show `git diff` output and offer to `git add`. Test plan: Here's a demo of the basic "happy path" (obviously monochrome, but it's colorized in real life). I tested a few variants along the way and it seems to work for everything that I threw at it. $ node bin/liferay-changelog-generator.js --interactive ____________________________________ (_) ` | | | @liferay/changelog-generator | | ============================ | | | | Reporting for duty! | | | |__________________________________| (_)_________________________________) [--interactive] Using phony version changelog-generator/v0.0.0-placeholder.0 Fetching remote tags: run with --no-update-tags to skip [--interactive] Preview of changes 👀 ## [changelog-generator/v0.0.0-placeholder.0](/~https://github.com/liferay/liferay-frontend-projects/tree/changelog-generator/v0.0.0-placeholder.0) (2020-10-16) [Full changelog](changelog-generator/v1.5.0...changelog-generator/v0.0.0-placeholder.0) ### 🆕 Features - feat(monorepo): use liferay-npm-scripts for formatting ([\#146](#146)) - feat(changelog-generator): make --version optional when --dry-run is on ([\#116](#116)) ### 📖 Documentation - docs(changelog-generator): update project links ([\#94](#94)) ### 🤹♀️ Refactoring - refactor(js-toolkit): make tests work in monorepo ([\#133](#133)) [--interactive] Would write ./CHANGELOG.md 7413 bytes ✨ 1. major 2. minor 3. patch 4. premajor 5. preminor 6. prepatch 7. prerelease Please choose a version from the list, or provide one in full (or enter to abort): 2 Wrote ./CHANGELOG.md 7371 bytes ✨ [--interactive] git-diff preview 👀 diff --git a/projects/npm-tools/packages/changelog-generator/CHANGELOG.md b/projects/npm-tools/packages/changelog-generator/CHANGELOG.md index fdf781a4..2ccfe5fa 100644 --- a/projects/npm-tools/packages/changelog-generator/CHANGELOG.md +++ b/projects/npm-tools/packages/changelog-generator/CHANGELOG.md @@ -1,3 +1,20 @@ +## [changelog-generator/v1.6.0](/~https://github.com/liferay/liferay-frontend-projects/tree/changelog-generator/v1.6.0) (2020-10-16) + +[Full changelog](changelog-generator/v1.5.0...changelog-generator/v1.6.0) + +### 🆕 Features + +- feat(monorepo): use liferay-npm-scripts for formatting ([\#146](#146)) +- feat(changelog-generator): make --version optional when --dry-run is on ([\#116](#116)) + +### 📖 Documentation + +- docs(changelog-generator): update project links ([\#94](#94)) + +### 🤹♀️ Refactoring + +- refactor(js-toolkit): make tests work in monorepo ([\#133](#133)) + ## [changelog-generator/v1.5.0](/~https://github.com/liferay/liferay-frontend-projects/tree/changelog-generator/v1.5.0) (2020-09-29) [Full changelog](changelog-generator/v1.4.1...changelog-generator/v1.5.0) Would you like to stage these changes? (y/n) y $ git status On branch wincent/version-shortcuts Your branch is ahead of 'master' by 6 commits. (use "git push" to publish your local commits) Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: CHANGELOG.md
This is still a bit rough (would like to follow up with a refactor commit), but it implements a basic `--interactive` mode which replaces this flow: npx @liferay/changelog-generator --dry-run # preview changes, decide on release type npx @liferay/changelog-generator --patch # actually generate changes git add -p # stage changes yarn version --patch # do release with this: npx @liferay/changelog-generator --interactive yarn version --patch It's a big ugly inside, but effectively we have a little state machine that goes through this cycle: 1. Run like `--dry-run`, and show a preview of what would be changed. 2. Prompt user for a version number (can be "major" etc or an explicit number). 3. Actually write out changes with the version number in effect. 4. Show `git diff` output and offer to `git add`. Test plan: Here's a demo of the basic "happy path" (obviously monochrome, but it's colorized in real life). I tested a few variants along the way and it seems to work for everything that I threw at it. $ node bin/liferay-changelog-generator.js --interactive ____________________________________ (_) ` | | | @liferay/changelog-generator | | ============================ | | | | Reporting for duty! | | | |__________________________________| (_)_________________________________) [--interactive] Using phony version changelog-generator/v0.0.0-placeholder.0 Fetching remote tags: run with --no-update-tags to skip [--interactive] Preview of changes 👀 ## [changelog-generator/v0.0.0-placeholder.0](/~https://github.com/liferay/liferay-frontend-projects/tree/changelog-generator/v0.0.0-placeholder.0) (2020-10-16) [Full changelog](changelog-generator/v1.5.0...changelog-generator/v0.0.0-placeholder.0) ### 🆕 Features - feat(monorepo): use liferay-npm-scripts for formatting ([\#146](#146)) - feat(changelog-generator): make --version optional when --dry-run is on ([\#116](#116)) ### 📖 Documentation - docs(changelog-generator): update project links ([\#94](#94)) ### 🤹♀️ Refactoring - refactor(js-toolkit): make tests work in monorepo ([\#133](#133)) [--interactive] Would write ./CHANGELOG.md 7413 bytes ✨ 1. major 2. minor 3. patch 4. premajor 5. preminor 6. prepatch 7. prerelease Please choose a version from the list, or provide one in full (or enter to abort): 2 Wrote ./CHANGELOG.md 7371 bytes ✨ [--interactive] git-diff preview 👀 diff --git a/projects/npm-tools/packages/changelog-generator/CHANGELOG.md b/projects/npm-tools/packages/changelog-generator/CHANGELOG.md index fdf781a4..2ccfe5fa 100644 --- a/projects/npm-tools/packages/changelog-generator/CHANGELOG.md +++ b/projects/npm-tools/packages/changelog-generator/CHANGELOG.md @@ -1,3 +1,20 @@ +## [changelog-generator/v1.6.0](/~https://github.com/liferay/liferay-frontend-projects/tree/changelog-generator/v1.6.0) (2020-10-16) + +[Full changelog](changelog-generator/v1.5.0...changelog-generator/v1.6.0) + +### 🆕 Features + +- feat(monorepo): use liferay-npm-scripts for formatting ([\#146](#146)) +- feat(changelog-generator): make --version optional when --dry-run is on ([\#116](#116)) + +### 📖 Documentation + +- docs(changelog-generator): update project links ([\#94](#94)) + +### 🤹♀️ Refactoring + +- refactor(js-toolkit): make tests work in monorepo ([\#133](#133)) + ## [changelog-generator/v1.5.0](/~https://github.com/liferay/liferay-frontend-projects/tree/changelog-generator/v1.5.0) (2020-09-29) [Full changelog](changelog-generator/v1.4.1...changelog-generator/v1.5.0) Would you like to stage these changes? (y/n) y $ git status On branch wincent/version-shortcuts Your branch is ahead of 'master' by 6 commits. (use "git push" to publish your local commits) Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: CHANGELOG.md
docs: fix small errors in security.md
This resolves disagreements between Prettier and ESLint about how comments should be formatted; eg. Prettier's preference:
vs ESLint's preference:
by passing everything through liferay-npm-scripts. It provides us a Prettier-like wrapper which abstracts over all this, and effectively runs Prettier + a post-processing pass under the covers.
This also means that we'll use the exact same formatting style in this repo as we use in liferay-portal.
Includes some necessary follow-up commits to ensure that our VSCode and Vim (etc) integrations keep working as expected. Note that I had to teach our
prettier
proxy the--list-different
option in order for it to be usable as a substitute in ourformat:check
job.Closes: #128