Conversation
4b77e95 to
73a6ba8
Compare
…e they end up finding node types there
|
The 1 failing test is the same as on main. |
machty
left a comment
There was a problem hiding this comment.
Looks awesome, thank you! Just some comments / questions but hopefully can merge ASAP!
| @@ -0,0 +1,151 @@ | |||
| // This file is generated by `vscode-ext-gen`. Do not modify manually. | |||
| // @see https://github.com/antfu/vscode-ext-gen | |||
There was a problem hiding this comment.
What's the rationale for versioning this file? Vue just has it run on the "postinstall" script. We can probably check it in but it would just mean more noise in diffs when adding commands or bumping versions.
There was a problem hiding this comment.
I've found lifecycle scripts to be kind of troll-y in the past, so I eliminated them.
That resulted in inlining the generate meta command in this library's test, because I kept getting errors about the generated-meta not existing.
I think this file, while small, is good to check in to source, because I feel like we'll need to know what's in here anyway to be good stewards of the upstream dependencies.
| - Run `yarn` in the root of the repo to install all the package dependencies. If you have Volta installed, it will automatically fetch and use the correct versions of Node and Yarn for you. | ||
| - Run `yarn build` in the root of the repository to build all of the projects the first time. This will make sure that once you start working on one of the packages, you are working with an up to date version of the other packages in the project it depends on. | ||
| - Run `pnpm install` in the root of the repo to install all the package dependencies. If you have Volta installed, it will automatically fetch and use the correct versions of Node and pnpm for you. | ||
| - Run `pnpm build` in the root of the repository to build all of the projects the first time. This will make sure that once you start working on one of the packages, you are working with an up to date version of the other packages in the project it depends on. |
There was a problem hiding this comment.
Adding a comment here in case some docs here might answer my question:
Don't have all the implications of peer deps and pnpm injected dependencies in my head, but I'm wondering what is the particular workflow when working on a workspace that uses injected deps? i.e. if I add or remove a file from one of the packages, what is the mechanism that add/removes that file from all of their referencing packages' node_moduies hard links? Is it a manual mechanism i need to periodically remember to run, or is it tied to some kind of watch script?
There was a problem hiding this comment.
I added a note to the CONTRIBUTING.md about sync, if needed.
but I'm wondering what is the particular workflow when working on a workspace that uses injected deps? i.e. if I add or remove a file from one of the packages, what is the mechanism that add/removes that file from all of their referencing packages' node_moduies hard links?
the either pnpm build or pnpm sync will update those hard links. This is configured in the .npmrc.
Is it a manual mechanism i need to periodically remember to run, or is it tied to some kind of watch script?
Unfortunately, there is no ability to have syncing in a watch script built in. I made this https://github.com/NullVoxPopuli/pnpm-sync-dependencies-meta-injected, but I don't yet know if it works with pnpm 10, and probably needs some tweaks to read the .npmrc, etc.
For now, the hard-links are synced whenever:
pnpm buildpnpm sync(a no-op, just syncs)
|
ope, sorry I missed it -- here is an update: #832 |
|
Awesome @NullVoxPopuli |
No description provided.