chore: set up initial actions & docs #1
Conversation
|
just throwing this previous conversation here nodejs/release-cloudflare-worker#132 - it's not a blocker, but i honestly dont know how to manage this sort of fragmentation across the project - perhaps it doesnt matter |
|
I think some fragmentation is fine. I think it's more important to keep standards similar. How they are enforced is an implementation detail, and the existing modus operandi of the project is, without a compelling reason to the contrary, that's author's choice. ESLint being "in the family" is maybe a compelling reason, but i think not a clear-cut one. I don't have much preference though. ESLint has been fine when I've used it before. I only tossed in biome here because of the reasons Augustin mentioned. |
This comment was marked as resolved.
This comment was marked as resolved.
Co-authored-by: Augustin Mauroy <[email protected]>
|
Should we have commit hooks ? |
| node-version: ${{ matrix.node-version }} | ||
| cache: 'npm' | ||
| - run: npm ci | ||
| - run: npm run lint |
There was a problem hiding this comment.
this should be done in sub steps ? I'm no sure.
@bmuenzenmeyer is more of an expert on this than I am
There was a problem hiding this comment.
its fine as long as you think linting and types go hand in hand here 👍
There was a problem hiding this comment.
Not especially, but the have the same setup and separating them into their own jobs seemed wasteful—no need to create a fresh environment for each; they don't affect each other.
There was a problem hiding this comment.
wasteful for who? actions are free.
Tests run in a matrix; linting only ever needs to run once; it’s generally best to split it for CI hygiene.
There was a problem hiding this comment.
Electricity? Spinning up a new environment may not cost us money, but it costs IRL resources—unless I'm misunderstanding what will happen?
| "javascript.updateImportsOnFileMove.enabled": "always", | ||
| "typescript.updateImportsOnFileMove.enabled": "always" |
There was a problem hiding this comment.
I think we need to set an additional property so that VS Code doesn't change d.ts → .js when it updates imports. I don't recall what the config prop is though.
There was a problem hiding this comment.
I've no idea, but I think this behaviour is gone now, but not for sure.
There was a problem hiding this comment.
Definitely not gone. It happened to me like yesterday.
This comment was marked as resolved.
This comment was marked as resolved.
Co-authored-by: Jacob Smith <[email protected]>
I think no: those can get hella annoying. If a user wants to commit code that will fail, that doesn't hurt anything, so let's not get in the way—maybe they have a good reason (like sharing something incomplete). |
I think include |
|
Looks like it was indeed the overly fancy glob—for whatever reason, CI does not like |
This reverts commit d081e4b.
|
I would like to support all LTS lines, but 20.x is maintenance mode with 24 around the corner. I think it's not awful to have not all recent lines because of the nature of these: a codemod run on a newer version can still process code intended for an older version. So let's remove 20.x from |
|
BTW if we not support node 20 we can only use |
JakobJingleheimer
requested review from
alexweej,
ljharb,
lukekarrys,
alexbit-codemod and
bmuenzenmeyer
| node-version: ${{ matrix.node-version }} | ||
| cache: 'npm' | ||
| - run: npm ci | ||
| - run: npm run lint |
There was a problem hiding this comment.
its fine as long as you think linting and types go hand in hand here 👍
| @@ -0,0 +1 @@ | |||
| 23 | |||
There was a problem hiding this comment.
do we recommend odd versions?
at least in my day job, we try to stay on the prod versions. I suppose this IS a tooling author environment 😄
There was a problem hiding this comment.
this IS a tooling author environment 😄
That's what I was thinking.
There was a problem hiding this comment.
may be use LTS for dev and recommend it for prod (cli usage of the tool)
There was a problem hiding this comment.
I think these would not be used in prod? @alexweej perhaps your use-case is different than what I'm imagining.
|
Noooo, why is CI failing on those globs again 😭 |
| - / # Location of package manifests | ||
| - /recipies/* | ||
| commit-message: | ||
| prefix: deps |
There was a problem hiding this comment.
| prefix: deps | |
| prefix: "deps(recipies): " |
There was a problem hiding this comment.
Maybe we should have 2 separate ones then so we can differentiate between the root repo and recipes (cuz if we apply your suggestion, it will mark changes to the root repo's deps as belonging to a recipe).
No description provided.