Conversation
| ### Lerna | ||
| https://lerna.js.org/ | ||
| https://github.com/ChristianMurphy/lerna-webjar |
There was a problem hiding this comment.
hmmm, a couple thoughts on this:
- lerna is (largely) being replaced by native monorepo/workspace features in npm and yarn
- lerna or workspaces are mostly useful when there are many web components that need to be managed.
There was a problem hiding this comment.
Do you see a value-add in keeping multiple web components bundled in the same repository? If we could go down to a single web component per repo, and then drop lerna, that'd definitely help simplify the toolset and allow web components the flexibility to be revised in isolation
There was a problem hiding this comment.
Do you see a value-add in keeping multiple web components bundled in the same repository?
Yes, but there are trade offs.
If the components are using the same technologies and interdependent.
Having a monorepo can help ensure we have consistency across toolchains, dependency versions, and release timing.
If the components are not using the same technologies and interdependent.
The value proposition for monorepos breaks down, and it can be more trouble than it's worth.
There was a problem hiding this comment.
makes sense. I'll note there are two flavors of build flows (npm/yarn & lerna)
There was a problem hiding this comment.
Lerna is for most intents and purposes deprecated, replaced by native monorepo workspace support in package managers, removing it from uPortal web components is something I hope to do sometime.
These days npm for a single repo and npm workspaces for a monorepo would be a go-to.
Yarn and pnpm could also be options, but lately they've been trending towards a new style of module loading called plug and play, which can break random modules and can be challenging to debug without fairly in depth knowledge of node js packaging conventions and module loading rules. I'd steer clear of these to keep the guide more beginner friendly.
| ### ESLint | ||
| https://eslint.org/ | ||
|
|
||
| Linter for Javascript. |
There was a problem hiding this comment.
ESLint starts with all rules off, and without framework specific guidance.
It would probably be good to recommend adding
- ESLint
- ESLint-prettier integration https://github.com/prettier/eslint-plugin-prettier
- ESLint plugin typescript https://github.com/typescript-eslint/typescript-eslint#readme
- ESLint plugin web components https://github.com/43081j/eslint-plugin-wc#readme
- ESLint plugin lit https://github.com/43081j/eslint-plugin-lit#readme
{
"root": true,
"parser": "@typescript-eslint/parser",
"extends": [
"eslint:recommended",
"plugin:prettier/recommended",
"plugin:@typescript-eslint/recommended",
"plugin:wc/best-practice",
"plugin:lit/recommended"
]
}| ### Typescript | ||
| https://www.typescriptlang.org/ | ||
|
|
||
| Type checking. |
There was a problem hiding this comment.
It may also be nice to include https://github.com/plantain-00/type-coverage#readme and encourage a minimum amount of typing (I personally prefer 100% types, but 90% could be a good baseline)
| ### StyleLint | ||
| https://stylelint.io/ | ||
|
|
||
| Linter for CSS. |
There was a problem hiding this comment.
Stylelint will need to be
- configured to support LIT https://dev.to/43081j/using-tailwind-postcss-and-stylelint-with-lit-element-projects-2hb9
- configured to not conflict with prettier https://github.com/prettier/stylelint-prettier#readme
- will need a rule set https://github.com/stylelint/stylelint-config-standard#readme
| ### Editor Config | ||
|
|
||
| Consistent code style in the IDE. |
There was a problem hiding this comment.
This feels optional with prettier, fine with keeping it though
| ### Remark | ||
| https://github.com/remarkjs/remark-lint | ||
|
|
||
| Linter for markdown. |
There was a problem hiding this comment.
This will also need a ruleset https://github.com/remarkjs/remark-lint#presets
I'd recommend remark-preset-lint-recommended and remark-preset-lint-consistent paired together.
| Linters | ||
| v | ||
| Pre-commit hooks |
There was a problem hiding this comment.
Ideally pre-commit hooks would trigger the linters automatically
| Deployed to Sonatype | ||
| v | ||
| Bundled as a webjar | ||
| v | ||
| Deployed to Maven |
There was a problem hiding this comment.
Aren't Sonatype and Maven central the same?
2 participants
No description provided.