Good product and a good developer experience. Yarn is about hidingĬomplexity, user convenience and happiness, and performance.Īs odd as that may sound - it's important to strike a balance of a This is direct opposite to what yarn is about. The underlying feeling I have is berry is optimizing for the maintainers, This may have a practical use case for it, e.g. Not a fan of how YN0000 shows everywhere. If it's not fitting the scenario - don't even Show practical examples of what type of projects these configuration My guess is the settings are to fill niche caches and specialized Overwhelmed byĮvery configuration option is listed, with no help given to making the 99% of the options berry has make no sense to me. With not adopting an incremental approach to make yarn v1 better.
It seems to decouple architecture (yay) but I'm concerned Why give it another name, unless losing track of where it came from It seems to be a project in the midst of a philosophical problem.
I imagine parsing the output of CLI tools in some way is a common enough use case that Yarn should have the flag to allow it without strange workarounds.Įven though we may not ultimately use it: This could also be worked around by piping the output through another command that removes that prefix from the output, but my intuition is that'd be prone to failure. This could be solved by modifying the regex in the problem matcher, but I believe it's out of scope for a tsc problem matcher to account for all kinds of wrappers that might be mutating the compiler's error format. I don't think there are any specific drawbacks to this feature in particular, but I'm unfamiliar with Yarn's codebase so I likely have blind spots here. Just the general drawback of having yet another flag/feature to maintain/test. I'd be willing to work on this PR if it's something that would be accepted. Yarn workspaces foreach -vpt -topological-dev -j 100 -raw-output run build I think yarn workspaces foreach should have a flag to suppress stuff like ➤ YN0000: from the output, or in other words a flag to get the raw unmodified output of the command(s) being run: In particular, it breaks on matching the file name, causing the annotation to end up in the wrong place. However, since I use yarn workspaces foreach, the output gets prefixed with Yarn's log level codes, causing the problem matcher to not match the output correctly. If my CI runs yarn run build on a workspace directly, the output is identical to the output of tsc, so the matcher works fine.
#YARN WORKSPACES FOREACH CODE#
That setup step by default includes a tsc problem matcher which uses regex to match the output of the Typescript compiler and annotate the code in a PR with the actual errors. I use GitHub Actions as my CI with the action to configure my CI environment for building my project. workspaces foreach -vpt -topological-dev -j 100 run buildĮach workspace's build script calls tsc with some flags. "watch": "ng build -watch -configuration development", "build": "ng build -configuration production", "build": "ng build components -configuration production",
"components": "yarn workspace "yarn workspace "yarn guide-app test & yarn components test",
#YARN WORKSPACES FOREACH INSTALL#
"npm": "Please use Yarn instead of NPM to install dependencies. "forceConsistentCasingInFileNames": true, The last step in the install says "Building Fresh Packages", but it doesn't trigger the build for the lib for some reason. If I run yarn on a fresh checkout at the root or yarn workspace app install, it installs everything and links to the lib's project folder, but it doesn't perform the build, which is necessary, since my tsconfig paths includes the output of the build dist/lib. rootĮach project has its associated build scripts. I have the library declared as a dependency of the app. I'm using Yarn workspaces (v1.22) on a monorepo with both an Angular app and library. I deleted my old question, to provide more info.
0 kommentar(er)
