Though this is true in some languages, or some projects with bespoke configuration systems, or in some editors. I don't mean that they don't work in the sense that they don't produce compileable import paths. > They’re pretty great these days, in my experience. We shouldn't admit defeat to the God of Complexity by saying, even in this small corner of good practices, "well, the comprehensibility of the import path doesn't matter because we gave up on making anything comprehensible a long time ago." That doesn't make the whole situation ideal, when talking in hypotheticals. But, they exist, and thus we have tools like Intellisense to make them manageable, and they'd definitely be less comprehensible without those tools. No one who has ever worked with one would say "this is the way the world should be". The reality that we have thousand-line source files obviously isn't ideal.
And they're even closer to the peak when you can combine that with encoded contextual information about the import path (which is generally a reflection of what the token does) into the token itself via, say, import aliasing or importing the module and accessing the token as a property on that imported module.
#Esbuild yarn workspaces code
Regardless of all of that: code files are near their peak productivity when they can fit on-screen without scrolling, and when you can put all that aside and just immediately move your eyes from the token to the import path. It depends on the language, the editor, and the development process. > Do y’all look at the import path at the top of a file to understand a function on line 450? # importing, then properly naming, the entire module is in my experience an underutilized tool to help with comprehension. Import * as createUserApiTypes from "foo/api/createUser/types" Ĭonst u = new createUserApiTypes.User() tsconfig.json at the root, extending shared/, including all things that an editor might care about shared/ directory at root that contains, , tsconfig.json (which is only symlinked to, has relative settings for the directories it's linked into) Lest we forget hoisting and dependency dedupe, which is far and away superior with pnpm. pnpm is faster than yarn 1 (variable with yarn 2, depending on use) and workspaces are just easier. Makes me want to write a counter article about using pnpm instead. Nice that they included a footnote about pnpm. Additionally, it prevents package duplication across workspaces and also makes it possible to create links between directories that depend on each other, ensuring that all directories are consistent in the monorepo. With Yarn Workspaces, installing packages across workspaces becomes faster and lighter.
0 kommentar(er)
