I opted to use which immediately proved to be an issue. To stress test Nx monorepos I decided to try creating a design system. It doesn’t touch on dependencies though - only Nx specific magic involving them. Package.json are supported in libraries and apps for defining publishable modules and development scripts. The poster raises a good point about using Docker.Īpparently in v13+ you can add a generatePackageJson flag to the build process. You can see an issue on Github about it where it’s emphasized you’re supposed to use the same version of dependencies across all modules. It kinda makes sense if everything is talking to each other, but if I have one module that supports a legacy version of React (or any of it’s dependencies), I’d have to pull it out into a separate project. This means you couldn’t have multiple versions of things like React in the same monorepo. Although Turborepo seems to take methods from package.json and run them - all of the configuration in Nx is custom stuff that can be confusing even to devs experienced with monorepos (although probably familiar to those devops engineers making YML pipelines).ĭifferent style of monorepo? All dependencies seem to be stored in root package.json - not individual package.json. This is similar to Turborepo, so it’s hard to hate. You’re still adding a Webpack build to a “package” or app, but it’s now piped through the project.json build pipeline. Setup is simplified, but things can be difficult to maintain or extend because it’s all contained in custom platform configurations and APIs. For example, in some cases the package.json doesn’t contain scripts - and they’re in a project.json file. Monorepos are handled in special config files.Ĭonfusing up-front to developers new to the monorepo style. I was able to import the Button into the app and see it (without pre-building library or anything - just yarn serve).Ī lot of platform specific configuration. And it exported the button from the library’s index.ts. This created a Button component in libs/ui/src/lib/button/button.tsx. _ import_ _from_ I made a component inside that UI library with: nx g button -project=ui -export It also updated the root tsconfig.json with a path alias to the lib, so I could import the components anywhere across the monorepo using the project name as a workspace and library name as the package (e.g. The library has a single component inside (presumably based on name we passed).
This created a React component library project configured with Typescript, Jest, ESLint, and Babel. I wanted components to use in the app, so I scaffolded a new library using the nx CLI for UI components: nx g ui The React app was stored in apps/react-gamepads and the Cypress tests were stored in apps/react-gamepads-e2e.
0 kommentar(er)
