docs(nx-dev): rename images with invalid Windows filenames
This commit is contained in:
Philip Fulcher
Juri Strumpflohner
parent
7c0e34400e
commit
c6bb33a49f
@ -2,7 +2,7 @@
|
||||
title: 'Step by Step Guide on Creating a Monorepo for React Native Apps using Nx'
|
||||
slug: 'step-by-step-guide-on-creating-a-monorepo-for-react-native-apps-using-nx'
|
||||
authors: ['Emily Xiong']
|
||||
cover_image: '/blog/images/2021-10-14/1*92uzyqB8oJ8tZJB9wAdoWQ.png'
|
||||
cover_image: '/blog/images/2021-10-14/92uzyqB8oJ8tZJB9wAdoWQ.png'
|
||||
tags: [nx, tutorial]
|
||||
---
|
||||
|
||||
@ -10,7 +10,7 @@ Do you want to have both mobile and web apps in the same repo? Do you wish that
|
||||
|
||||
It goes through how to create a simple 2-page app that shows your daily horoscope based on your zodiac sign.
|
||||
|
||||
|
||||
|
||||
_Screenshots of Daily Horoscope App_
|
||||
|
||||
TL;DR — GitHub repo: [xiongemi/aztro-daily-horoscope](https://github.com/xiongemi/aztro-daily-horoscope)
|
||||
@ -44,7 +44,7 @@ nx generate application **daily-horoscope-app**
|
||||
|
||||
This should generate `daily-horoscope-app` folder under apps:
|
||||
|
||||
|
||||
|
||||
_daily-horoscope-app folder_
|
||||
|
||||
Now you install the starter project of Nx React Native. If you run:
|
||||
@ -144,7 +144,7 @@ nx generate lib models
|
||||
|
||||
This should generate a models folder under libs:
|
||||
|
||||
|
||||
|
||||
_models folder under libs_
|
||||
|
||||
Then under this models folder, create a file to have the below enum that contains all the zodiac signs:
|
||||
@ -300,14 +300,14 @@ export default App;
|
||||
|
||||
If you run `nx run-ios daily-horoscope-app` and `nx run-android daily-horoscope-app`, you should see something like:
|
||||
|
||||
|
||||
|
||||
_Left: iOS simulator, right: Android simulator_
|
||||
|
||||
You have created the first page of your app.
|
||||
|
||||
If you run the command `nx dep-graph`, you should see what the dependency graph looks like below:
|
||||
|
||||
|
||||
|
||||
_Dependency graph_
|
||||
|
||||
The next step is to handle action when users pressed on a list item. To achieve that, it is going to use Redux.
|
||||
@ -561,14 +561,14 @@ Since the code is running in simulators, how to use the Redux Devtools extension
|
||||
|
||||
Open the debug menu in the simulator by entering `d` in the terminal that runs the start command. Then in the debug menu, choose “Debug with Chrome” for iOS and “Debug” for Android.
|
||||
|
||||
|
||||
|
||||
_Debug Menu in iOS and Android_
|
||||
|
||||
Install tool React Native Debugger: [https://github.com/jhen0409/react-native-debugger](https://github.com/jhen0409/react-native-debugger).
|
||||
|
||||
Now inside React Native Debugger, you should be able to use Redux Devtools and Redux Logger. Now if you press any zodiac sign from the list, you should see action `horoscope/setUserZodiacSignItem` got dispatched and the state is updated.
|
||||
|
||||
|
||||
|
||||
_React Native Debugger_
|
||||
|
||||
Now you have successfully set up the Redux store for your app. The next step is to navigate to a different screen when you have successfully selected a zodiac sign.
|
||||
@ -648,7 +648,7 @@ export default App;
|
||||
|
||||
If you run the code in the simulator, the app should look similar to before except for the header.
|
||||
|
||||
|
||||
|
||||
_Add React Navigation in iOS and Android simulator_
|
||||
|
||||
### Create Second Page
|
||||
@ -782,7 +782,7 @@ export const ZodiacSignListContainer = connect(
|
||||
|
||||
Now you should be able to navigate between 2 screens.
|
||||
|
||||
|
||||
|
||||
_Navigate between 2 screens_
|
||||
|
||||
## Integrate with API
|
||||
@ -1214,14 +1214,14 @@ In the App component, replace `HoroscopeCard` with `HoroscopeCardContainer`:
|
||||
|
||||
Now when you run the app, it should display the horoscope according to the zodiac user selected.
|
||||
|
||||
|
||||
|
||||
_Horoscope Card integrated with API_
|
||||
|
||||
Finally, you got a mobile app that runs on both Android and iOS. You could reuse the libraries to create a web app.
|
||||
|
||||
If you run command `nx dep-graph`, you should see the dependency graph looks like below:
|
||||
|
||||
|
||||
|
||||
_Dependency Graph_
|
||||
|
||||
## Create Web App
|
||||
@ -1367,12 +1367,12 @@ Also in `workspace.json`, change the webpackConfig under daily-horoscope-web to
|
||||
|
||||
Now if you run `nx serve daily-horoscope-web`, it should the web app in the browser.
|
||||
|
||||
|
||||
|
||||
_Web App_
|
||||
|
||||
Now the dependency graph should look like:
|
||||
|
||||
|
||||
|
||||
_Dependency Graph_
|
||||
|
||||
## Conclusion
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Taming Code Organization with Module Boundaries in Nx'
|
||||
slug: 'mastering-the-project-boundaries-in-nx'
|
||||
authors: ['Miroslav Jonaš']
|
||||
cover_image: '/blog/images/2021-12-17/1*PIUl1QGk7mOpSFdEwFQ8OA.png'
|
||||
cover_image: '/blog/images/2021-12-17/PIUl1QGk7mOpSFdEwFQ8OA.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -79,7 +79,7 @@ Finally, the flag `enforceBuildableLibDependency` prevents us from importing a n
|
||||
|
||||
To best express the need for the boundaries and assist us through the explanation, we will be using the repository represented by the following graph:
|
||||
|
||||
|
||||
|
||||
_The graph representation of the repository_
|
||||
|
||||
Our repository consists of two applications — Store and Admin. Each of them is composed of several feature libraries — Products (for Store), Sales, and Invoices (for Admin). Also, both of these applications depend on the Core library, and every project in our repo depends on our Shared library. Using common sense, we would like to enforce certain boundaries:
|
||||
@ -109,7 +109,7 @@ Your changed project configuration should now have the tags section defined.
|
||||
|
||||
Your enhanced graph will now look similar to this:
|
||||
|
||||
|
||||
|
||||
_Graph with type tags set_
|
||||
|
||||
The above list of library types is not complete. You might add specific ones for E2E projects or UI component libraries. Using the naming format `type:*` is just a suggestion. Consider this being a hashtag on your favorite social app. You can use any prefix or format you feel fitting. The important thing is that it's readable and intuitive to all the members of your team.
|
||||
@ -149,7 +149,7 @@ Now, that we have marked all of our projects, we can continue to define the rule
|
||||
|
||||
We said that a feature library can depend on any other feature library, but there is a small catch. Our two apps could be built with a different framework so mixing feature libraries would not be possible. To avoid any future impediments, we don’t want to allow a feature library used in `Store` to depend on the feature library from `Admin` and vice versa. Additionally, only our apps should be able to load the `Core` library.
|
||||
|
||||
|
||||
|
||||
_Project graph with type tags and technology badges_
|
||||
|
||||
Let’s add another dimension to allow such restrictions. We will define the necessary scope tags:
|
||||
@ -161,7 +161,7 @@ Let’s add another dimension to allow such restrictions. We will define the nec
|
||||
|
||||
Our diagram should now look like this:
|
||||
|
||||
|
||||
|
||||
_Full project graph with two-dimensional tags_
|
||||
|
||||
Let us now define our missing rules!
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Single File Monorepo Config, Custom Workspace Presets, Improved Tailwind Support, and more in Nx 13.4!'
|
||||
slug: 'single-file-monorepo-config-custom-workspace-presets-improved-tailwind-support-and-more-in-nx-13'
|
||||
authors: ['Brandon Roberts']
|
||||
cover_image: '/blog/images/2021-12-23/1*_4u3Fw49H5U-sqgyBoGsqw.png'
|
||||
cover_image: '/blog/images/2021-12-23/4u3Fw49H5U-sqgyBoGsqw.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -12,7 +12,7 @@ Nx is a smart, extensible build framework to help you architect, test, and build
|
||||
|
||||
Nx reached a major milestone this week of one million weekly downloads. Nx has been working to push monorepos forward for a long time, and this milestone is a reflection of work between us and the Nx community to grow and expand in this space.
|
||||
|
||||
|
||||
|
||||
_One million weekly downloads_
|
||||
|
||||
## Single File Monorepo Configuration ☝️
|
||||
@ -55,7 +55,7 @@ Read all the details on [our new TypeScript guide](/getting-started/intro) or ch
|
||||
|
||||
## Improved Tailwind support for Angular 💅
|
||||
|
||||
|
||||
|
||||
_Tailwind Logo_
|
||||
|
||||
Tailwind is a utility-first CSS framework packed with classes that can be composed to build any design, directly in your markup. If you’ve used Tailwind with Angular applications previously, it's supported out of the box with Nx. We’re continually looking to improve the developer experience of using Tailwind in Angular applications and libraries. We already added support to the Angular plugin for Nx, and have added a new generator to configure Tailwind in **existing** apps and buildable/publishable libs, allowing you to set up and configure Tailwind without manual steps. The ability to configure new apps and libs is also supported, with support for Tailwind V2 and the latest V3 release.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'New Terminal Output & Performance Improvements in Nx 13.5'
|
||||
slug: 'new-terminal-output-performance-improvements-in-nx-13-5'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2022-01-25/1*PIUl1QGk7mOpSFdEwFQ8OA.png'
|
||||
cover_image: '/blog/images/2022-01-25/PIUl1QGk7mOpSFdEwFQ8OA.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -12,7 +12,7 @@ Nx is a smart, extensible build framework to help you architect, test, and build
|
||||
|
||||
Folks that have been following along in our journey for quite some time know already that at Nx we strive for the best possible DX. The current terminal output was always something we haven’t been super happy with, especially if you run some of the commands that trigger the execution of multiple tasks (e.g. affected commands, run-many etc). This is why we’re even more excited about this feature: the new dynamic Nx terminal output is now the default for everyone.
|
||||
|
||||
|
||||
|
||||
_New dynamic terminal output in Nx 13.5_
|
||||
|
||||
It clearly separates the terminal output into an upper part where all the completed tasks and their corresponding execution time are listed and a lower part where the currently running tasks show up. Of course, errors are always shown immediately and therefore easy to spot.
|
||||
@ -39,7 +39,7 @@ When running an Nx command there might potentially be many tasks running at diff
|
||||
|
||||
That’s why we introduced the ability to profile and visualize Nx commands in the Chrome Devtools.
|
||||
|
||||
|
||||
|
||||
|
||||
Use the `NX_PROFILE=<filename>` environment variable attached to your Nx CLI command:
|
||||
|
||||
@ -64,7 +64,7 @@ The project graph is always a nice feature to show off in videos, talks, and blo
|
||||
|
||||
In v13.5 we now also store the current filter status in the URL. That makes it easy to pinpoint a certain view and share it with a co-worker. Actually, this could just be the beginning of some more interesting features when we think about CI and visualizations 🤔.
|
||||
|
||||
|
||||
|
||||
_Nx dep graph now stores filters in the URL_
|
||||
|
||||
Here’s our deployed live example of the above screenshot: [https://nrwl-nx-examples-dep-graph.netlify.app/?focus=products-home-page](https://nrwl-nx-examples-dep-graph.netlify.app/?focus=products-home-page)
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Set up Tailwind CSS with Angular in an Nx workspace'
|
||||
slug: 'set-up-tailwind-css-with-angular-in-an-nx-workspace'
|
||||
authors: ['Leosvel Pérez Espinosa']
|
||||
cover_image: '/blog/images/2022-01-28/1*igoocYqr8gj8n9t8qr5cuA.png'
|
||||
cover_image: '/blog/images/2022-01-28/igoocYqr8gj8n9t8qr5cuA.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -20,7 +20,7 @@ The final result of what we are going to be building can be found in this Github
|
||||
|
||||
We are going to create 2 simple applications with the following layout:
|
||||
|
||||
|
||||
|
||||
_Applications mockup_
|
||||
|
||||
We’ll start by creating one application with the required markup and **Tailwind CSS** utility classes to achieve the above layout. Then, we’re going to leverage **Nx**’s library support and extract some common UI components into 2 different shared libraries:
|
||||
@ -200,7 +200,7 @@ npx nx run app1:serve
|
||||
|
||||
Visiting [https://localhost:4200](https://localhost:4200) in your browser should show the application looking like the following screenshot:
|
||||
|
||||
|
||||
|
||||
_Application 1 screenshot_
|
||||
|
||||
That’s it! We have successfully created our application to fulfill the requirements we had. Next, we are going to start extracting pieces of the UI into shared libraries to reuse them with the second application.
|
||||
@ -260,7 +260,7 @@ Since we have our application configured to scan the relevant files within itsel
|
||||
|
||||
Below is a small decision tree to check whether a **Tailwind CSS** configuration is needed for your library in an **Nx** workspace:
|
||||
|
||||
|
||||
|
||||
_Decision tree for the need of Tailwind CSS configuration in Angular libraries_
|
||||
|
||||
## Extracting the header into a library
|
||||
@ -655,7 +655,7 @@ Once again, if we serve our application everything should still be working as ex
|
||||
|
||||
Also, if we visualize the workspace projects we’ll see how `app1` and `lib2` now have a dependency on `tailwind-preset`:
|
||||
|
||||
|
||||
|
||||
_Project graph showing dependencies between the projects in the workspace_
|
||||
|
||||
## Creating the second application
|
||||
@ -782,7 +782,7 @@ npx nx run app2:serve
|
||||
|
||||
Now, open your browser and navigate to it where you should see the application looking like the following screenshot:
|
||||
|
||||
|
||||
|
||||
_Application 2 screenshot_
|
||||
|
||||
That does indeed look different, but something is off. The card background color is not right, it’s still the same used for `app1` even though we provided a different theme. Also, some of the spacing for the elements within the card doesn’t seem to have changed according to our configuration.
|
||||
@ -896,7 +896,7 @@ We need to do the same for `app1`. Edit the `apps/app1/src/styles.css` file with
|
||||
|
||||
Let’s serve again `app2` and navigate to it to check the results of our changes:
|
||||
|
||||
|
||||
|
||||
_Application 2 screenshot_
|
||||
|
||||
Now we are talking!
|
||||
@ -1200,7 +1200,7 @@ npx nx run lib3:build
|
||||
|
||||
If we check the output folder `dist/libs/lib3`, we’ll see there’s a `themes` folder in it with a couple of files `indigo.css` and `teal.css`:
|
||||
|
||||
|
||||
|
||||
_Publishable library with the produced theme files highlighted_
|
||||
|
||||
These theme files can now be used by the consumers of our library to properly style the components exposed by it. All they would need to do is to import one of those themes into their application styles entry point or `index.html` file.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Share code between React Web & React Native Mobile with Nx'
|
||||
slug: 'share-code-between-react-web-react-native-mobile-with-nx'
|
||||
authors: ['Emily Xiong']
|
||||
cover_image: '/blog/images/2022-02-01/1*lL-fGNaIGYBC_eOBwSvdBw.png'
|
||||
cover_image: '/blog/images/2022-02-01/lL-fGNaIGYBC_eOBwSvdBw.png'
|
||||
tags: [nx, tutorial]
|
||||
---
|
||||
|
||||
@ -10,7 +10,7 @@ tags: [nx, tutorial]
|
||||
|
||||
I am mostly a web developer, so let’s start with the web app first: [https://xiongemi.github.io/studio-ghibli-search-engine](https://xiongemi.github.io/studio-ghibli-search-engine). It is a search engine for movies and characters under Studio Ghibli:
|
||||
|
||||
|
||||
|
||||
_Screenshot of web app_
|
||||
|
||||
Example Repo: [xiongemi/studio-ghibli-search-engine](https://github.com/xiongemi/studio-ghibli-search-engine)
|
||||
@ -27,7 +27,7 @@ Now let’s create the corresponding mobile version of this app.
|
||||
|
||||
Currently, there’s only a React web app within our Nx workspace. If I run `nx graph`, the dependency graph looks like the below:
|
||||
|
||||
|
||||
|
||||
_Dependency graph_
|
||||
|
||||
## React Native Setup
|
||||
@ -50,12 +50,12 @@ npx nx generate @nrwl/react-native:app studio-ghibli-search-engine-mobile
|
||||
|
||||
As a result of running the above command, you should now have two new folders under the `apps` directory: `studio-ghibli-search-engine-mobile` and `studio-ghibli-search-engine-mobile-e2e`
|
||||
|
||||
|
||||
|
||||
_studio-ghibli-search-engine-mobile created under apps_
|
||||
|
||||
If we now run `nx dep-graph` again, the dependency graph looks like this:
|
||||
|
||||
|
||||
|
||||
_Dependency graph_
|
||||
|
||||
Note that there is no code shared between `studio-ghibli-search-engine-mobile` and `studio-ghibli-search-engine-web`. However, our goal is to reuse some of the functionality that we have previously written for the web version on our new React native version of the app.
|
||||
@ -325,7 +325,7 @@ With Nx, it requires zero configuration to share the above library code. Even th
|
||||
|
||||
For example, I need to create a film page to display film details with film id passed in as a parameter:
|
||||
|
||||
|
||||
|
||||
_Screenshot of Film Page on Mobile (left: iOS, right: Android)_
|
||||
|
||||
I would do import from the store library directly:
|
||||
@ -454,12 +454,12 @@ Note I could import from `@studio-ghibli-search-engine/models`, `@studio-ghibli-
|
||||
|
||||
Now when I run `nx dep-graph`, it shows the dependency graph below where all these 3 libraries are shared between web and mobile:
|
||||
|
||||
|
||||
|
||||
_Dependency graph_
|
||||
|
||||
For this example project, to create the mobile app, it took me some time to rewrite the entire UI. However, I do not need to make any changes to the above libraries.
|
||||
|
||||
|
||||
|
||||
_Screenshots of Mobile App (left: iOS, right: Android)_
|
||||
|
||||
## Conclusion
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Introducing Expo Support for Nx'
|
||||
slug: 'introducing-expo-support-for-nx'
|
||||
authors: ['Emily Xiong']
|
||||
cover_image: '/blog/images/2022-03-23/1*yYc8g4ifk9RApSjAhQysag.png'
|
||||
cover_image: '/blog/images/2022-03-23/yYc8g4ifk9RApSjAhQysag.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -10,7 +10,7 @@ We are very excited to announce our support for Expo with our new package `@nrwl
|
||||
|
||||
This blog will show you how to create a one-page app to display a poem:
|
||||
|
||||
|
||||
|
||||
_Page Screenshot (left: Android, right: iOS)_
|
||||
|
||||
Github Repo: [xiongemi/nx-expo-poetry](https://github.com/xiongemi/nx-expo-poetry)
|
||||
@ -21,7 +21,7 @@ When I just started to try out Expo, the first questions came to my mind were
|
||||
|
||||
Now I have created an app with Expo, to me, the most significant differences are developer experience and the build process.
|
||||
|
||||
|
||||
|
||||
_Left: managed Expo project folder, right: React Native project folder_
|
||||
|
||||
For a managed Expo project, notice that it only has a `src` folder; whereas for a React Native project, besides the `src` folder, it also contains the `android` and `ios` folder. For a managed Expo project, developers do not need to worry about maintaining code for iOS and Android. However, you can still write customized native code for Expo, you can use Expo with [bare workflow](https://docs.expo.dev/introduction/managed-vs-bare/#bare-workflow) after running the command `expo eject`.
|
||||
@ -57,7 +57,7 @@ nx generate @nrwl/expo:app poetry-app
|
||||
|
||||
Now you should notice that under the apps folder, there are 2 folders generated: `peotry-app` and `poetry-app-e2e:`
|
||||
|
||||
|
||||
|
||||
_apps folder_
|
||||
|
||||
Now run the command to serve up the Expo Development Server:
|
||||
@ -68,7 +68,7 @@ nx start poetry-app
|
||||
|
||||
You should see the starter app in the simulator:
|
||||
|
||||
|
||||
|
||||
_Expo Development Server_
|
||||
|
||||
## Create First Page
|
||||
@ -93,7 +93,7 @@ nx g @nrwl/expo:component poem-of-the-day --directory=components
|
||||
|
||||
Now you should see the components under apps/components:
|
||||
|
||||
|
||||
|
||||
|
||||
Then paste the below code to the `App.tsx` and `poem-of-the-day.tsx`:
|
||||
|
||||
@ -159,7 +159,7 @@ export default PoemOfTheDay;
|
||||
|
||||
Now, if you run command `nx start poetry-app` and then run the app on the simulator, you should see:
|
||||
|
||||
|
||||
|
||||
_Page Screenshot (left: Android, right: iOS)_
|
||||
|
||||
To see it in the real device, run `nx publish poetry-app`.
|
||||
@ -176,7 +176,7 @@ nx generate @nrwl/expo:library services
|
||||
|
||||
This should generate a services folder under libs:
|
||||
|
||||
|
||||
|
||||
|
||||
Create a `poetry.service.ts` file to call the PoetryDB API and get a random poem:
|
||||
|
||||
@ -219,7 +219,7 @@ Then the `apps/poetry-app/src/components/poem-of-the-day/poem-of-the-day.tsx` wo
|
||||
|
||||
If you now run the app using `nx start poetry-app`, you should see the poem loaded from API:
|
||||
|
||||
|
||||
|
||||
_Page Screenshot (left: Android, right: iOS)_
|
||||
|
||||
## Using Expo Build
|
||||
@ -242,7 +242,7 @@ nx build-android poetry-app
|
||||
|
||||
You can monitor your builds after logging in at [https://expo.dev/](https://expo.dev/):
|
||||
|
||||
|
||||
|
||||
_Builds page at https://expo.dev/_
|
||||
|
||||
You can read more at [https://docs.expo.dev/classic/building-standalone-apps/](https://docs.expo.dev/classic/building-standalone-apps/) to debug.
|
||||
@ -269,7 +269,7 @@ eas build
|
||||
|
||||
You can monitor your builds after logging in at [https://expo.dev/](https://expo.dev/):
|
||||
|
||||
|
||||
|
||||
_Builds page at https://expo.dev/_
|
||||
|
||||
To submit to the app store, run:
|
||||
@ -303,5 +303,5 @@ Android:
|
||||
|
||||
iOS:
|
||||
|
||||
|
||||
|
||||
_Screenshot in iOS app store_
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'The React CLI you always wanted but didn’t know about'
|
||||
slug: 'the-react-cli-you-always-wanted-but-didnt-know-about'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2022-03-29/1*YR6QUEZel3nlNcTo6Pdlwg.png'
|
||||
cover_image: '/blog/images/2022-03-29/YR6QUEZel3nlNcTo6Pdlwg.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -67,14 +67,14 @@ import { someFunc } from '@myorg/somelib';
|
||||
|
||||
What you’ll get is a setup wizard that guides you through creating your application. We would most likely choose “React” in this case.
|
||||
|
||||
|
||||
|
||||
_Nx CLI guides through the setup process_
|
||||
|
||||
As part of this process, you’ll be asked to pick an “Application name”. This is simply the application Nx is going to generate for us to get started: `happynrwl` would be a nice name 🙂.
|
||||
|
||||
You should end up with a new Nx workspace and our `happynrwl` React app in the `apps/` folder.
|
||||
|
||||
|
||||
|
||||
_Layout of a Nx workspace in VSCode_
|
||||
|
||||
## Serving our React app
|
||||
@ -89,7 +89,7 @@ npx nx serve happynrwl
|
||||
|
||||
Going to [http://localhost:4200](http://localhost:4200/) should show the running React app located in `apps/happynrwl`.
|
||||
|
||||
|
||||
|
||||
_Welcome screen when launching the React application with Nx_
|
||||
|
||||
## Build our React app
|
||||
@ -102,7 +102,7 @@ npx nx build happynrwl
|
||||
|
||||
This should build the app into `dist/apps/happynrwl`, which we can then take and deploy to wherever we want to deploy it.
|
||||
|
||||
|
||||
|
||||
_Output folder assets when building the React app_
|
||||
|
||||
Nx has another nice feature that basically comes for free: [computation caching](/concepts/how-caching-works). For every command Nx runs, it computes a unique hash that contains information about the involved source code, environment variables and the command itself. Next time the same conditions are met, the command is not executed again, but rather pulled out of a cache. As you can imagine, this drammatically speeds up things.
|
||||
@ -121,7 +121,7 @@ npx nx generate @nrwl/react:component HelloWorld
|
||||
|
||||
This generates a new component in our `happynrwl` application
|
||||
|
||||
|
||||
|
||||
_Example of a React component generated by Nx_
|
||||
|
||||
> _Note, you can also use_ `_nx g @nrwl/react..._` _as a shorthand for_ `_generate_`_. Also, if you attach_ `_--dry-run_` _to the end of the command it will just simulate the run without touching the file system._
|
||||
@ -161,7 +161,7 @@ Every new Nx workspace comes with [ESLint](https://eslint.org/) already preconfi
|
||||
|
||||
Every project generated by Nx comes with a `.eslintrc.json` file. That configuration extends from an ESLint plugin `@nrwl/nx/react` , containing a set of best practices rules, and at the same time allows you to add further rules that are specific to your needs.
|
||||
|
||||
|
||||
|
||||
_ESLint configuration in an Nx workspace_
|
||||
|
||||
Linting can be run similarly to the other commands:
|
||||
@ -176,7 +176,7 @@ Similar to the linting setup, every project in an Nx workspace has a test runner
|
||||
|
||||
At the root of every project, there’s a `jest.config.js` which already comes with proper transformers to support TypeScript and TSX/JSX. If you need to further customize how Jest should behave for this project, this is the place to do that.
|
||||
|
||||
|
||||
|
||||
_Jest configuration in an Nx workspace_
|
||||
|
||||
Running Jest tests is as easy as
|
||||
@ -194,7 +194,7 @@ Obviously, you can pass parameters to customize the Jest run, like
|
||||
|
||||
If you happen to use [VSCode](https://code.visualstudio.com/), the easiest way however is to install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) and leverage its code lens feature to run and debug Jest tests:
|
||||
|
||||
|
||||
|
||||
_Using VSCode extensions to run Jest tests directly via Code Lens support_
|
||||
|
||||
## Cypress preconfigured!
|
||||
@ -203,7 +203,7 @@ _Using VSCode extensions to run Jest tests directly via Code Lens support_
|
||||
|
||||
Whenever you generate a new project in an Nx workspace, you have the option to automatically also create a Cypress-based e2e project alongside it. In our case, it is called `happynrwl-e2e`.
|
||||
|
||||
|
||||
|
||||
_Cypress e2e app generated by Nx along-side the main React app_
|
||||
|
||||
The awesome part of this is that you don’t have to configure anything at all. No need to
|
||||
@ -232,7 +232,7 @@ npx nx format
|
||||
|
||||
## Nx Console — A dedicated VSCode extension for Nx
|
||||
|
||||
|
||||
|
||||
|
||||
Nx really is an advanced CLI based development tool. But regardless of whether you are a command line person or not, if you happen to use [VSCode](https://code.visualstudio.com/) make sure you install the [Nx Console extension](/getting-started/editor-setup) from the [marketplace](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console).
|
||||
|
||||
@ -240,7 +240,7 @@ Nx really is an advanced CLI based development tool. But regardless of whether y
|
||||
|
||||
Once you have the extension installed, you can click its icon in the VSCode Activity Bar (1) which reveals the Nx Console UI.
|
||||
|
||||
|
||||
|
||||
_Nx Console VSCode extension_
|
||||
|
||||
A couple of things:
|
||||
@ -251,12 +251,12 @@ A couple of things:
|
||||
|
||||
Let’s take the example of generating a new React component, just as we did before, but this time using Nx Console. This is how you’d do that:
|
||||
|
||||
|
||||
|
||||
_Actions to generate a new React component with Nx Console_
|
||||
|
||||
Once you click the entry in the dropdown list, the Nx Console generate form opens, showing all the options the Nx generator supports:
|
||||
|
||||
|
||||
|
||||
_Detail form shown by Nx Console to generate a new React component_
|
||||
|
||||
Whenever you change something in the form (1), you’ll automatically see a dry-run in the console that opens below (2). That shows what would happen if you run the command and is equivalent of adding the `--dry-run` flag whenever you’d run the command on the terminal. Once you’re ready, hit the “Run” button (3), or click the copy symbol (4) to copy the full command into your clipboard s.t. you can then paste it into your terminal.
|
||||
@ -265,7 +265,7 @@ As you can see this approach is also really powerful for exploring different com
|
||||
|
||||
Besides running generators, Nx Console also adds [VSCode Code Lens](https://code.visualstudio.com/blogs/2017/02/12/code-lens-roundup) abilities to the configuration files that help you navigate more quickly across the workspace. This is particularly useful if you happen to add more [apps and libraries](/concepts/decisions/project-size) to the workspace at some point.
|
||||
|
||||
|
||||
|
||||
_Nx Console Code Lens support to navigate easily among config files_
|
||||
|
||||
## Evergreen Workspace Setup
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'What is new in Nx 13.10?'
|
||||
slug: 'what-is-new-in-nx-13-10'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2022-04-08/1*PJ3SRAadq0DxGiC9mCIWsA.png'
|
||||
cover_image: '/blog/images/2022-04-08/PJ3SRAadq0DxGiC9mCIWsA.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -24,7 +24,7 @@ Read more on the docs: [/guides/nx-daemon](/concepts/nx-daemon)
|
||||
|
||||
When you set up a new Nx workspace with `create-nx-workspace` the question about opting into Nx Cloud will be pointed on “Yes” by default now.
|
||||
|
||||
|
||||
|
||||
_Nx Cloud opt-in when setting up a new Nx workspace_
|
||||
|
||||
## Build and run Nx Plugins locally in your Nx workspace
|
||||
@ -37,7 +37,7 @@ Nx can be used in a wide range of scenarios, from small open source projects, st
|
||||
|
||||
This illustration should give you a rough idea. obviously some of the plugins may be built on top of others, leveraging common functionality. An example is the [@nrwl/js](/nx-api/js) plugin which not only can be used as a standalone plugin but also builds the basis for of many others by providing core JavaScript/TypeScript features.
|
||||
|
||||
|
||||
|
||||
|
||||
You can just use the [Nx core without any plugins](/getting-started/intro) to get started and later decide to add more plugins such as `@nrwl/react` or `@nrwl/js` etc depending on your specific use case.
|
||||
|
||||
@ -84,7 +84,7 @@ where `@myorg` is your Nx workspace name you defined and `workspace-extensions`
|
||||
|
||||
We keep improving our project graph and make it more and more useful for visually exploring your Nx workspace. You can now click on an edge and list the files that cause it which can be extremely valuable during debugging.
|
||||
|
||||
|
||||
|
||||
_Improved Project Graph visualization showing information about the edges that connect nodes_
|
||||
|
||||
And this is just a sneak peak of what’s coming in Nx v14, so stay tuned!
|
||||
@ -93,7 +93,7 @@ And this is just a sneak peak of what’s coming in Nx v14, so stay tuned!
|
||||
|
||||
Having a decent monorepo setup is not always just about speed but also to have features in place that help you keep your code-base healthy and maintainable in the long run. The Nx module boundary lint rules are an example for that.
|
||||
|
||||
|
||||
|
||||
_Tagging Nx projects_
|
||||
|
||||
By assigning tags to your projects you can then configure which relationships among libraries and applications are allowed, and which are forbidden.
|
||||
@ -152,7 +152,7 @@ More on Miroslav’s tweet:
|
||||
|
||||
Whether by accident or by letting your IDE auto-add the import. It often happens that the path that is being used is via the library’s TS path mapping through the `index.ts` entry point. This leads to a circular dependency when also `tslib-c-another.ts` is exported via the `index.ts`. Nx’s module boundary lint rule correctly highlights this as can be seen in this screenshot.
|
||||
|
||||
|
||||
|
||||
_Self circular dependency issue within a Nx based library_
|
||||
|
||||
Adjusting these circular self references is easy, but can be cumbersome to find the correct imports and time consuming if you have hundreds of libs that might be affected by this. In the latest version of Nx we shipped a fix implementation for these lint rules, such that you can now conveniently add `--fix` to auto-adjust the imports:
|
||||
@ -163,17 +163,17 @@ npx nx lint tslib-c --fix
|
||||
|
||||
This will analyze your imports, find the correct file and adjust them accordingly:
|
||||
|
||||
|
||||
|
||||
_Automatic adjustment of circular self references when running the lint rule fix_
|
||||
|
||||
Similarly if you have relative or absolute imports across library boundaries rather than using the NPM scope, you’ll get a linting error.
|
||||
|
||||
|
||||
|
||||
_Lint error about relative import across library boundaries_
|
||||
|
||||
Such imports will also be adjusted by applying the `--fix` to your linting command:
|
||||
|
||||
|
||||
|
||||
_Automatic fixes for cross-library imports_
|
||||
|
||||
## React 18 support
|
||||
@ -221,14 +221,14 @@ Here are some of the highlights in the latest Nx Console release.
|
||||
|
||||
You can now open the VSCode Command menu (Cmd + Shift + P or Win + Shift + P) and enter “Nx: Run Target” to invoke the Run Target menu which allows to choose the target to run as well as the project to execute the target on.
|
||||
|
||||
|
||||
|
||||
_Commands can be invoked from the VSCode Command menu_
|
||||
|
||||
## Run Target View now in sync with workspace commands
|
||||
|
||||
While initially the “Generate and Run Target” panel was a static list of the usual Nx targets, it is now a dynamically generated list based on your actual workspace commands. Hence, also your custom defined targets will automatically show up.
|
||||
|
||||
|
||||
|
||||
_Nx Console dynamically reads Nx targets from your Nx workspace now_
|
||||
|
||||
## Prompts for Angular CLI users
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Use Storybook with Nx React Native'
|
||||
slug: 'use-storybook-with-nx-react-native'
|
||||
authors: ['Emily Xiong']
|
||||
cover_image: '/blog/images/2022-04-25/1*64nWVfUBihlYTLGWOvnc1g.png'
|
||||
cover_image: '/blog/images/2022-04-25/64nWVfUBihlYTLGWOvnc1g.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -14,7 +14,7 @@ Example Repo: [xiongemi/studio-ghibli-search-engine](https://github.com/xiongemi
|
||||
|
||||
Storybook:
|
||||
|
||||
|
||||
|
||||
_Storybook View (left: Android, right: iOS)_
|
||||
|
||||
## Setup
|
||||
@ -41,7 +41,7 @@ As shown in the example below, 3 folders got generated:
|
||||
- `.storybook` in your app or lib
|
||||
- `storybook` in your app (Note: this folder is for creating the Storybook UI component. It will only be created for the app, you will not see this for lib.)
|
||||
|
||||
|
||||
|
||||
|
||||
If you choose to automatically generate `*.stories` file, you should see the default story looks like below:
|
||||
|
||||
@ -124,12 +124,12 @@ nx run-android <your app>
|
||||
|
||||
In your simulator/emulator/device, open the Debug Menu by entering `d` in terminal. You should see the menu option Toggle Storybook in the Debug Menu:
|
||||
|
||||
|
||||
|
||||
_Screenshot of Debug menu (left: Android, right: iOS)_
|
||||
|
||||
When switching on the toggle, you should see the list of your component stories:
|
||||
|
||||
|
||||
|
||||
_Storybook View (left: Android, right: iOS)_
|
||||
|
||||
### View Storybook for Lib
|
||||
@ -152,7 +152,7 @@ Then just run the command to start your app, you should see the storybook for yo
|
||||
|
||||
If you are using the library `@react-navigation/native` and you are using hooks like `useNavigtion` and `useRoute` inside your component, you are likely to get the below error:
|
||||
|
||||
|
||||
|
||||
_Render Error for Couldn’t find a navigation object_
|
||||
|
||||
The easiest way is just to mock this library and create a [decorator](https://storybook.js.org/docs/react/writing-stories/decorators) for it:
|
||||
@ -224,7 +224,7 @@ const NavigationDecorator = (story) => {
|
||||
|
||||
If you are using Redux store and your component is stateful and connected to the store, you are likely to get the below error:
|
||||
|
||||
|
||||
|
||||
_Render Error for Could not find “store”_
|
||||
|
||||
The simple solution is to mock the store. First, you need to install the library [redux-mock-store](https://github.com/reduxjs/redux-mock-store) and its typing:
|
||||
@ -274,7 +274,7 @@ storiesOf('PeopleListItem', module)
|
||||
|
||||
If you use an async action (for example, an action created using `createAsyncThunk` from `@reduxjs/toolkit`), you would likely run into the below error: Actions must be plain objects.
|
||||
|
||||
|
||||
|
||||
_Render Error for Actions must be plain objects_
|
||||
|
||||
Now to resolve this, add thunk to mock store middleware:
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Nx v14 is out — Here is all you need to know!'
|
||||
slug: 'nx-v14-is-out-here-is-all-you-need-to-know'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2022-05-02/1*UAN1p_RMt38_IvB3CRpYTA.png'
|
||||
cover_image: '/blog/images/2022-05-02/UAN1p_RMt38_IvB3CRpYTA.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -22,7 +22,7 @@ We hit a major milestone with Nx v13 when we reached 1 million weekly downloads
|
||||
|
||||
Nx also outgrew Lerna in February in weekly downloads. Up until that point, [Lerna](https://lerna.js.org/) was considered the go-to choice when it comes to JS-based monorepos. But just recently, they made it [even more evident](https://github.com/lerna/lerna/pull/3092) that Lerna has been and is [largely unmaintained](https://github.com/lerna/lerna/issues/2703).
|
||||
|
||||
|
||||
|
||||
|
||||
We saw that coming and made it easy for people to migrate to Nx.
|
||||
|
||||
@ -34,7 +34,7 @@ There’s a detailed guide helping with some of the doubts and misconceptions wh
|
||||
|
||||
The future for monorepo tools looks bright as the awareness of monorepos, especially in the JS ecosystem, has grown a lot in recent months. Nx is doing great compared to those tools. But this movement excites us and we are more than ever committed to keep pushing forward and making Nx even better.
|
||||
|
||||
|
||||
|
||||
|
||||
## Nx Console reaches 1 million installs
|
||||
|
||||
@ -63,7 +63,7 @@ How can Nx be so fast? One thing we did introduce after v13 and [recently enable
|
||||
|
||||
While a lot of the above improvements help with local development, one of the biggest pain points of having a large monorepo can be CI times. This is where **distributed task execution (DTE)** makes all the difference\*_._\* Nx Cloud’s DTE understands which commands your CI is running, how many agents are typically being used, and how long a given task typically takes. It leverages that information along with task dependencies to create an execution plan that prioritizes builds of shared libraries first to unblock upstream builds. This results in a more even utilization of CI agents, optimizing the overall running time of your CI.
|
||||
|
||||
|
||||
|
||||
|
||||
Over time, Nx Cloud’s DTE learns about your workspace, keeping metrics about running times to allow the best possible distribution of a given task with the given amount of agents. This comes with Nx Cloud.
|
||||
|
||||
@ -87,11 +87,11 @@ Developer experience is highly important to us. And that doesn’t stop at the t
|
||||
|
||||
_(here executed by skipping the cache to show some progress running_ 🙂*)*
|
||||
|
||||
|
||||
|
||||
|
||||
We now even filter out the build of dependent projects. Say you build the `react` project in your workspace which depends on 11 other projects. Nx needs to first incrementally build those 11 dependent projects, which it does now in a very subtle way by just reporting the overall progress at the top of the terminal output, while the main `react` project build output is printed just as normal.
|
||||
|
||||
|
||||
|
||||
|
||||
Obviously, all errors would be reported properly, and on CI this behavior is disabled by default. If you want to disable it, you can always set `NX_TASKS_RUNNER_DYNAMIC_OUTPUT` to false.
|
||||
|
||||
@ -134,7 +134,7 @@ npx nx generate @nrwl/workspace:ci-workflow --ci=github
|
||||
|
||||
Or just use [Nx Console](/getting-started/editor-setup), as always.
|
||||
|
||||
|
||||
|
||||
|
||||
This sets you up with an automated CI workflow that properly uses the Nx affected command together with the power of [Nx Cloud’s distributed task execution](/ci/features/distribute-task-execution).
|
||||
|
||||
@ -144,11 +144,11 @@ You can also use the `--all` flag when generating a new workspace, for seeing al
|
||||
|
||||
The [Nx Cloud GitHub app](https://github.com/apps/nx-cloud) is so useful for not having to go to your CircleCI logs and try to find the entry you’re searching for. Instead all the executed targets nicely show up as a comment in your PR.
|
||||
|
||||
|
||||
|
||||
|
||||
Once you click them, you get a nicely formatted and structured page within Nx Cloud.
|
||||
|
||||
|
||||
|
||||
|
||||
Until now, you had to have a task that is being executed through Nx Cloud. But what about those workspace utility scripts, like checking the commit format etc. You can now use `nx-cloud record` for those, like
|
||||
|
||||
@ -176,7 +176,7 @@ nx g @nrwl/angular:host shell --remotes=shop,cart,about
|
||||
|
||||
By specifying the `implicitDependencies` in Nx ([see docs](/reference/project-configuration)) Nx knows what the relation between the various apps is, even though there are not direct imports
|
||||
|
||||
|
||||
|
||||
|
||||
Combining this with the power of Nx Cloud distributed caching, you can now serve your shell project
|
||||
|
||||
@ -209,31 +209,31 @@ Read more on our docs: [/concepts/module-federation/micro-frontend-architecture]
|
||||
|
||||
You asked for it, the community responded. [Luís Carvalho](https://github.com/Lcarv20) - a first time contributor - worked together with Nx core team members Philip and Ben to deliver dark mode for the project graph visualization!!
|
||||
|
||||
|
||||
|
||||
|
||||
Also, have you ever wondered whether in your gigantic graph there’s a connection between two nodes?
|
||||
|
||||
|
||||
|
||||
|
||||
Now you can easily find out! Just click on a node and hit the “Start” button.
|
||||
|
||||
|
||||
|
||||
|
||||
Then click the target node you’re interested in and hit “End”.
|
||||
|
||||
|
||||
|
||||
|
||||
The project graph now renders the path between those nodes.
|
||||
|
||||
|
||||
|
||||
|
||||
And by clicking on the edges you can even get a more detailed output of why the connection exists in the first place 🤯
|
||||
|
||||
|
||||
|
||||
|
||||
Oh wait, you didn’t want the shortest path? There’s a button for showing all possible paths too 😉
|
||||
|
||||
|
||||
|
||||
|
||||
## JavaScript & TypeScript library support
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Lerna is dead — Long Live Lerna'
|
||||
slug: 'lerna-is-dead-long-live-lerna'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2022-05-11/1*__gtsrJ-tMDZf9bvDLVSjQ.png'
|
||||
cover_image: '/blog/images/2022-05-11/gtsrJ-tMDZf9bvDLVSjQ.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'How Lerna just got 10x faster!'
|
||||
slug: 'lerna-used-to-walk-now-it-can-fly'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2022-05-25/1*WPGHapKqT3IguWjeN5UgWg.png'
|
||||
cover_image: '/blog/images/2022-05-25/WPGHapKqT3IguWjeN5UgWg.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -31,7 +31,7 @@ But let’s do some more real “apples-to-apples” comparison of Lerna’s spe
|
||||
|
||||
Here’s a gif of running the benchmark of Lerna+Nx and Turborepo:
|
||||
|
||||
|
||||
|
||||
|
||||
**Lerna+Nx is 5.3 times faster** than Turborepo 🚀.
|
||||
|
||||
@ -82,7 +82,7 @@ By having Nx integrated, you not just get faster builds but also some other Nx
|
||||
|
||||
[**Nx Project graph**](/features/explore-graph) — By running `npx nx graph` you get the visualization of the graph. You can interactively explore what your workspace looks like and the relationships between the packages. We actually used this same graph on the Lerna repo itself, which helped us to get a better understanding of how the repo is structured when we took over the maintenance. Here’s an example of filtering the lerna packages to understand what `@lerna/exec` is about and how it relates to other packages in the repo.
|
||||
|
||||
|
||||
|
||||
|
||||
**Distributed caching** — Right now when you enable `useNx` in your existing Lerna repo, you will get local caching, meaning the cache sits in a local folder on your machine. You get much more value out of it when you start distributing and sharing it with your teammates but especially in CI. This can be done by adding Nx Cloud, which comes with a no-credit card, 500 hours free / month offer which is more than what most workspaces need. Adding that is easy and can be done by adding `@nrwl/nx-cloud` to your root-level `package.json` and then by running:
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Setup a Monorepo with PNPM workspaces and speed it up with Nx!'
|
||||
slug: 'setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2022-07-14/1*ABrBjQPg4SrYzFQQXFxY-Q.png'
|
||||
cover_image: '/blog/images/2022-07-14/ABrBjQPg4SrYzFQQXFxY-Q.png'
|
||||
tags: [nx, tutorial]
|
||||
---
|
||||
|
||||
@ -139,7 +139,7 @@ You should now be able to serve your Remix app in dev-mode by using:
|
||||
pnpm --filter my-remix-app dev
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## Create a Shared UI library
|
||||
|
||||
@ -327,7 +327,7 @@ pnpm --filter shared-ui build
|
||||
|
||||
Why? This is due to the symlinks PNPM creates in order to be able to reference and resolve local dependencies. By adding `shared-ui: "workspace:*"` to Remix's `package.json` you instruct PNPM to add a symlink to Remix's `node_modules` folder.
|
||||
|
||||
|
||||
|
||||
_PNPM creates a symlink in the local node_modules folder to be able to import local packages_
|
||||
|
||||
## Running commands with PNPM
|
||||
@ -629,7 +629,7 @@ Here’s the entire `nx.json` file again as a reference point:
|
||||
|
||||
If we now run `npx nx build my-remix-app` we can see that Nx first runs tasks on dependent projects, and only then runs the command we invoked.
|
||||
|
||||
|
||||
|
||||
|
||||
_Nx highlights dependent projects being built, but it keeps the main attention to the current task at hand without distracting_
|
||||
|
||||
@ -650,7 +650,7 @@ You can use any target you have defined in your workspace. For example
|
||||
|
||||
**How does this work?** Nx builds a project graph based on the structure and dependencies among packages in your monorepo workspace. Let’s assume the following hypothetical graph:
|
||||
|
||||
|
||||
|
||||
|
||||
_Potential graph of a monorepo workspace_
|
||||
|
||||
@ -666,7 +666,7 @@ Whenever we run the affected commands on a branch, Nx compares all the commits a
|
||||
|
||||
If `lib2` gets changed in our feature branch, running tests against the workspace using `affected:test` would only run tests for `lib2` and `appB`.
|
||||
|
||||
|
||||
|
||||
|
||||
_Affected projects if “lib2” gets changed_
|
||||
|
||||
@ -709,7 +709,7 @@ packages/shared-ui build: Done
|
||||
|
||||
When using Nx to run tasks you get a dynamic terminal that shows just what is necessary and most relevant to the current command that has been executed. Running the same parallel build task results in the following output when using Nx:
|
||||
|
||||
|
||||
|
||||
_Terminal output of Nx dynamically showing the parallel tasks being computed as well as the ones that already succeeded_
|
||||
|
||||
## Project Graph Visualization
|
||||
@ -720,7 +720,7 @@ npx nx graph
|
||||
|
||||
This launches an interactive visualization of the workspace’s project graph with some advanced capabilities of filtering, debugging your workspace structure and more.
|
||||
|
||||
|
||||
|
||||
_Nx project graph visualization of our PNPM workspace_
|
||||
|
||||
> _As a side-note: you can run the project graph on any PNPM workspace, even if you don’t have Nx installed. Running_ `_npx nx graph_` _should work._
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Helping the Environment by Saving Two Centuries of Compute time'
|
||||
slug: 'helping-the-environment-by-saving-two-centuries-of-compute-time'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2022-08-18/1*FBQVoC9YXF7wlq3dhxfQMQ.png'
|
||||
cover_image: '/blog/images/2022-08-18/FBQVoC9YXF7wlq3dhxfQMQ.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -12,7 +12,7 @@ Among the core features of Nx is the ability to save computation time by applyin
|
||||
|
||||
This is how much got saved so far (data from August 16th, 2022). Pretty crazy!
|
||||
|
||||
|
||||
|
||||
|
||||
Here are the raw numbers:
|
||||
|
||||
@ -26,19 +26,19 @@ Calculating the CO2 emissions can be tricky. It really depends on what machines
|
||||
|
||||
**Last 7-day savings correspond to:**
|
||||
|
||||
|
||||
|
||||
|
||||
[See all the details](https://green-algorithms.org//?runTime_hour=46752&runTime_min=0&appVersion=v2.2&locationContinent=North+America&locationCountry=United+States+of+America&locationRegion=US&coreType=CPU&numberCPUs=2&CPUmodel=Xeon+E5-2683+v4&memory=4&platformType=cloudComputing&provider=aws)
|
||||
|
||||
**Last 30-day savings correspond to:**
|
||||
|
||||
|
||||
|
||||
|
||||
[See all the details](https://green-algorithms.org//?runTime_hour=207462&runTime_min=0&appVersion=v2.2&locationContinent=North+America&locationCountry=United+States+of+America&locationRegion=US&coreType=CPU&numberCPUs=2&CPUmodel=Xeon+E5-2683+v4&memory=4&platformType=cloudComputing&provider=aws)
|
||||
|
||||
**Since the beginning of Nx Cloud:**
|
||||
|
||||
|
||||
|
||||
|
||||
[See all the details](https://green-algorithms.org//?runTime_hour=1760505&runTime_min=0&appVersion=v2.2&locationContinent=North+America&locationCountry=United+States+of+America&locationRegion=US&coreType=CPU&numberCPUs=2&CPUmodel=Xeon+E5-2683+v4&memory=4&platformType=cloudComputing&provider=aws)
|
||||
|
||||
@ -62,7 +62,7 @@ This helps save computation by reducing the set of projects that need to be proc
|
||||
|
||||
Nx comes with a so-called [computation caching](/concepts/how-caching-works) feature. For every cacheable operation, Nx takes a set of input parameters, computes a hash and stores the result.
|
||||
|
||||
|
||||
|
||||
|
||||
Whenever a hash matches, the computation is not run, but rather the previous result is restored. This can dramatically speed up things and avoid running any computation that has already been run previously.
|
||||
|
||||
@ -72,7 +72,7 @@ By default, the Nx computation cache is stored locally (usually within the `node
|
||||
|
||||
[Nx Cloud](/nx-cloud) allows to distribute the Nx computation cache across machines.
|
||||
|
||||
|
||||
|
||||
|
||||
Connecting an existing Nx workspace to Nx Cloud can be done with
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Lerna reborn — What’s new in v6?'
|
||||
slug: 'lerna-reborn-whats-new-in-v6'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2022-10-12/1*RGQCNNO-SSQ8PHnIZ4BVTQ.png'
|
||||
cover_image: '/blog/images/2022-10-12/RGQCNNO-SSQ8PHnIZ4BVTQ.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -75,7 +75,7 @@ By using Nx as the task scheduler for Lerna it inherits all the capabilities Nx
|
||||
|
||||
Remote caching allows you to distribute your local cache with your co-workers and your CI system. This is done via [Nx Cloud](/nx-cloud). But distributed caching is just one aspect. Nx Cloud also comes with a “run view” that visualizes your CI run with easy grouping and filtering capabilities, but in particular, it comes with the ability to distribute your tasks dynamically across multiple machines. All by optimizing for the best parallelization and machine utilization.
|
||||
|
||||
|
||||
|
||||
|
||||
All you need to set this up is to run..
|
||||
|
||||
@ -139,7 +139,7 @@ You can now finally use one of the fastest package managers in combination with
|
||||
|
||||
When running tasks in parallel across a large number of projects, it can become quite difficult to follow along in the terminal with what got built and where tasks failed. That’s why the new Lerna version comes with a dynamic terminal output that only shows what is most relevant at a given moment.
|
||||
|
||||
|
||||
|
||||
|
||||
Note that you would still see all of the output as usual on CI.
|
||||
|
||||
@ -147,21 +147,21 @@ Note that you would still see all of the output as usual on CI.
|
||||
|
||||
Lerna now has a [dedicated VSCode extension](https://lerna.js.org/docs/features/editor-integrations) to help you navigate your monorepo. This allows you to run commands directly from the context menu (by right-clicking on a project):
|
||||
|
||||
|
||||
|
||||
|
||||
Or visualize a project and its relationships with other projects in the workspace.
|
||||
|
||||
|
||||
|
||||
|
||||
You will also get intelligent autocompletion in configuration files. Here’s an example of Nx console providing context-based information when editing the `nx.json` task dependencies.
|
||||
|
||||
|
||||
|
||||
|
||||
## Lerna Repair
|
||||
|
||||
Lerna v6 comes with a built-in `lerna repair` command. Running this command will automatically fix your Lerna configuration. For instance, in Lerna v6, there's no need to have `useNx: true` in your `lerna.json` since that will be the new default going forward. Running `lerna repair` fixes this.
|
||||
|
||||
|
||||
|
||||
|
||||
This allows you always to have the most up-to-date Lerna setup and it will become even more powerful as we keep adding migrations in the future.
|
||||
|
||||
|
||||
@ -2,26 +2,26 @@
|
||||
title: 'From Bootstrapped to Venture-Backed: Nx Raises $8.6M'
|
||||
slug: 'from-bootstrapped-to-venture-backed'
|
||||
authors: ['Jeff Cross']
|
||||
cover_image: '/blog/images/2022-11-17/0*a3eT-mjLsXTiHU5m.png'
|
||||
cover_image: '/blog/images/2022-11-17/a3eT-mjLsXTiHU5m.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
I’m excited to let the Nx Community know about our first round of outside financing, led by [Nexus Venture Partners](https://nexusvp.com/) and [A16z](https://a16z.com/), with several amazing angel investors. We’ve raised a seed round of $8.6M to scale the growth of open source Nx, [Nx Cloud](/nx-cloud), and [Nx Enterprise](/enterprise). With this new capital, we’re able to allocate significantly more resources to rapidly evolving our open source and commercial products to help development teams **ship faster at any scale**.
|
||||
|
||||
|
||||
|
||||
_Just a few of the companies powered by Nx_
|
||||
|
||||
When Victor Savkin and I left Google to start this company in December 2016, we saw a big gap between how enterprises were building software and how companies like Google were building software. So in 2017, we released the first version of our developer toolkit, Nx, which focused on enabling monorepo-style development for large software teams. Nx has continued to evolve and grow in adoption since then, at more than 5x year-over-year in npm downloads to now 12M+ monthly downloads! We’re proud that the world’s top brands depend on Nx to help their development teams iterate faster on critical products.
|
||||
|
||||
|
||||
|
||||
|
||||
[Nx Cloud](/nx-cloud) has also seen a significant uptake in adoption, thanks in large part due to the addition of [Distributed Task Execution](/ci/concepts/parallelization-distribution) last year. With the combination of Distributed Task Execution and Distributed Caching, Nx Cloud is having a massive impact on the time it takes to validate and merge pull requests, drastically reducing product time-to-market. There are now more than 100k connected Nx Workspaces on nx.app. With Nx Cloud, Nx and Lerna workspaces can drastically reduce build times by letting Nx Cloud manage task cache distribution, and optimal distribution of tasks across many machines using Nx’s deep understanding of project relationships and task timings. We’ve determined that Nx and Nx Cloud have [saved over 250 years of compute time](blog/helping-the-environment-by-saving-two-centuries-of-compute-time) since we started measuring.
|
||||
|
||||
|
||||
|
||||
|
||||
Our most significant commercial innovation in the past year has been [Nx Enterprise](/enterprise), which allows companies to deploy Nx Cloud on their own infrastructure. Some of the world’s leading brands are relying on Nx Enterprise to help their developers get products and features to market significantly faster. One repository powered by Nx Enterprise is saving over 40,000 hours per month of compute time thanks to Distributed Caching and Distributed Task Execution, drastically reducing the time it takes to validate and merge pull requests.
|
||||
|
||||
|
||||
|
||||
_Monorepo.tools, by Nx in collaboration with other monorepo projects_
|
||||
|
||||
With Nx and Lerna under our stewardship, we now maintain [more than 75% of leading JavaScript monorepo tooling](https://npmtrends.com/@bazel/typescript-vs-@microsoft/rush-vs-@nrwl/tao-vs-lerna-vs-turbo). We’re sharing this space with some other great teams, who are all pushing the state of the art forward. We developed the site [monorepo.tools](https://monorepo.tools/) in collaboration with these teams to spread the monorepo love and help developers decide which tool is right for them.
|
||||
@ -32,7 +32,7 @@ Victor Savkin and I originally decided not to raise funding when starting the co
|
||||
|
||||
We couldn’t be more excited to partner with our co-lead investors, [Nexus Venture Partners](https://nexusvp.com/) and [Andreesen Horowitz (a16z)](https://a16z.com/). Both firms have deep expertise in developer tooling and strongly believe in our vision of helping development teams scale. We’re excited to have them bring their own unique talents, experience, and resources to help us execute on that vision. Abhishek Sharma from Nexus has tremendous commercial open source experience, and has been excited about Nx for years. A16z is a powerhouse with an extremely talented enterprise infrastructure team led by Martin Casado and Jennifer Li, alongside amazing partners including, Satish Talluri, and Yoko Li. We’re also excited to be joined by many angels, including Tom Preston-Werner, Matt Biilmann, and several other notable CEOs, founders and technologists.
|
||||
|
||||
|
||||
|
||||
_Most of the Nx team at Nx Conf in Tempe, AZ, October 2022_
|
||||
|
||||
We are only scratching the surface of how we can help teams scale their development, and we’re drastically increasing our R&D time to move even faster on new innovations in build performance and team scaling. Fortunately, we already have a world-class team of top engineers who’ve helped us build Nx and Nx Cloud, while also helping our customers succeed with Nx. With this new capital, our engineers are able spend significantly more R&D time building industry-changing products and features, while continuing to work with and learn from our Nx Cloud and Nx Enterprise customers.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Nx 15.3 — Standalone Projects, Vite, Task Graph and more!'
|
||||
slug: 'nx-15-3-standalone-projects-vite-task-graph-and-more'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2022-12-06/1*VXYjjWhOUpNuHFGCoF63OQ.png'
|
||||
cover_image: '/blog/images/2022-12-06/VXYjjWhOUpNuHFGCoF63OQ.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -43,7 +43,7 @@ For most of our workforce, working on Nx and Nx Cloud was only part of their “
|
||||
|
||||
On to 4 million!
|
||||
|
||||
|
||||
|
||||
|
||||
## New Task Graph Visualization
|
||||
|
||||
@ -71,7 +71,7 @@ Therefore, let me introduce you the **task graph**. You might already be used to
|
||||
|
||||
You can add another project as well, showing what the task graph looks like for a command that runs tasks for multiple projects like `nx run-many` or `nx affected`. Click on the `Group by project` checkbox to group related tasks by their project, and click on a task to see what executor it uses.
|
||||
|
||||
|
||||
|
||||
|
||||
## Standalone Projects
|
||||
|
||||
@ -81,13 +81,13 @@ Nx is widely known as [THE developer tool](https://monorepo.tools/) people look
|
||||
|
||||
But one stands out most prominently: the **ability to easily modularize** your codebase.
|
||||
|
||||
|
||||
|
||||
|
||||
A lot of our users adopt Nx for precisely this reason. They have a large app and want to break it into smaller pieces while still having the comfort of deploying it as a single one.
|
||||
|
||||
In 15.3 we are therefore making **standalone projects** a first-class feature. Suppose you now create a new workspace with `npx create-nx-workspace` alongside the usual monorepo options. In that case, you will now see two more options for scaffolding a standalone React or Angular application (we will add more in the future).
|
||||
|
||||
|
||||
|
||||
|
||||
In a standalone project setup, you don’t have the typical `apps` and `libs` structure you might be accustomed to if you have been using Nx in the past. Instead, the app lives directly at the root of your workspace. The structure looks similar to the following:
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Nx 15.4 — Vite 4 Support, a new Nx Watch Command, and more!'
|
||||
slug: 'nx-15-4-vite-4-support-a-new-nx-watch-command-and-more'
|
||||
authors: ['Zack DeRose']
|
||||
cover_image: '/blog/images/2022-12-22/1*N4_XxtYFr-V2cF6fPoBO3g.png'
|
||||
cover_image: '/blog/images/2022-12-22/N4_XxtYFr-V2cF6fPoBO3g.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -25,7 +25,7 @@ Prefer a **video version**?
|
||||
|
||||
Nx 15.4 brings in the latest Vite major version following the Vite 4 release earlier this month.
|
||||
|
||||
|
||||
|
||||
|
||||
As the [Vite launch article](https://vitejs.dev/blog/announcing-vite4.html) mentions, we are investing in the Vite ecosystem, and now officially support a first-party Vite plugin. Nx 15.4 continues this investment with timely support for Vite 4, and we’re excited to be a part of the Vite ecosystem and a part of bringing more value to our devs through Vite support!
|
||||
|
||||
@ -78,7 +78,7 @@ Check out [our docs](/recipes/running-tasks/workspace-watching) for more details
|
||||
|
||||
## Webpack-less Cypress Support for Our React Standalone preset
|
||||
|
||||
|
||||
|
||||
_Running e2e with React Standalone Projects_
|
||||
|
||||
We added a React Standalone preset in 15.3 to support single react application workspaces with Nx, and in 15.4, we’ve added back in Cypress for this preset.
|
||||
@ -87,7 +87,7 @@ With Nx 15.4, a standalone React application will be created with an e2e directo
|
||||
|
||||
## Server-Side Rendering support for Module Federation for both Angular and React Applications
|
||||
|
||||
|
||||
|
||||
|
||||
Now you can get the benefits of both Server Side Rendering and Module Federation for your applications, which will improve page loads, Search Engine Optimization, and build times!
|
||||
|
||||
@ -121,7 +121,7 @@ Last but not least, we’ve added support for interactive prompts for Custom Pre
|
||||
|
||||
In Nx, [presets](/extending-nx/recipes/create-preset#create-a-custom-plugin-preset) are special code generation scripts that can be used to create a brand new Nx Workspace, using our `create-nx-workspace` command.
|
||||
|
||||
|
||||
|
||||
|
||||
For instance, I happen to know [Shai Reznik](https://twitter.com/shai_reznik) at [builder.io](https://builder.io/) has been working on a qwik plugin for Nx, and since the [qwik-nx](https://www.npmjs.com/package/qwik-nx) plugin that he’s published includes an [Nx generator called “preset”](https://github.com/qwikifiers/qwik-nx/blob/main/packages/qwik-nx/generators.json#L33), I can run the command:
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Setting up Module Federation with Server-Side Rendering for Angular'
|
||||
slug: 'setting-up-module-federation-with-server-side-rendering-for-angular'
|
||||
authors: ['Colum Ferry']
|
||||
cover_image: '/blog/images/2023-01-10/1*kyMChnJ-X6jK9sbuaOdOiw.png'
|
||||
cover_image: '/blog/images/2023-01-10/kyMChnJ-X6jK9sbuaOdOiw.png'
|
||||
tags: [nx, tutorial]
|
||||
---
|
||||
|
||||
@ -27,11 +27,11 @@ Now we can get both, the benefits of Module Federation and SSR in our Nx Workspa
|
||||
|
||||
A traditional SSR application is rendered on the server. It receives the requested route from the browser, Angular evaluates that route, and the server generates the HTML and sends it back to the browser.
|
||||
|
||||
|
||||
|
||||
|
||||
With Module Federation and SSR, it takes that concept and the concept of MF to allow portions of the app to be run on their own server. The host server will receive the route and if it’s a route pointing to a remote, it will ask the remote to process the route, then send the rendered HTML to the browser.
|
||||
|
||||
|
||||
|
||||
|
||||
This gives us full power of SSR but also still allowing us to break our build into multiple smaller builds. It also means that we _could_ redeploy the remote server with new changes without having to redeploy the host server, allowing for independent deployability of features within the overall application.
|
||||
|
||||
@ -93,11 +93,11 @@ Compiled successfully.
|
||||
|
||||
Let’s open a new tab in our browser, and open Network tab in the DevTools. After this, navigate to [http://localhost:4200](http://localhost:4200/). You should see the following:
|
||||
|
||||
|
||||
|
||||
|
||||
The most interesting piece here is the first entry in the network log. Let’s look at it more closely:
|
||||
|
||||
|
||||
|
||||
|
||||
We can see that the server returned the fully rendered HTML for the page!
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'React, Vite and TypeScript: Get started in under 2 minutes'
|
||||
slug: 'react-vite-and-typescript-get-started-in-under-2-minutes'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2023-01-12/1*ucL7YQ2v8aaOy426soLPZA.png'
|
||||
cover_image: '/blog/images/2023-01-12/ucL7YQ2v8aaOy426soLPZA.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -63,11 +63,11 @@ npx create-nx-workspace@latest awesomereactapp
|
||||
|
||||
And then choose the option you prefer in the terminal prompt:
|
||||
|
||||
|
||||
|
||||
|
||||
In the end, what you’ll get is the following structure:
|
||||
|
||||
|
||||
|
||||
|
||||
## Running, building and testing the app
|
||||
|
||||
@ -248,7 +248,7 @@ export default defineConfig({
|
||||
|
||||
Nx is known for its caching that helps optimize the speed in monorepos. Caching takes the inputs (the command, source files, environment variables…) and computes a hash.
|
||||
|
||||
|
||||
|
||||
|
||||
On every run, Nx compares that hash against a local cache folder. If the hash exists, Nx restores the command line output and potential artifacts (JS, CSS,… files) produced by a previous run. This helps speed up computation because you don’t run it if you don’t need to.
|
||||
|
||||
@ -384,11 +384,11 @@ Another side-effect of splitting up your codebase into libraries is that your co
|
||||
npx nx graph
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
It becomes even more interesting if you select the “Group by folder” checkbox as the domains become visible at that point:
|
||||
|
||||
|
||||
|
||||
|
||||
> _Note this is a hypothetical app to demo some of the features of the Nx graph visualization. Some of the connections might only make a little sense._
|
||||
|
||||
@ -453,7 +453,7 @@ Let’s say we make a change in the `product-detail` library of our application.
|
||||
npx nx affected:graph
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
To run tasks only for the affected areas, use:
|
||||
|
||||
@ -473,11 +473,11 @@ If you are not the “command line interface type” developer and you’d rathe
|
||||
|
||||
It has a dedicated view within VSCode to trigger common commands, browse the workspace structure and even inline render the graph.
|
||||
|
||||
|
||||
|
||||
|
||||
It also comes with contextual menus to quickly access most of the commonly used functionality:
|
||||
|
||||
|
||||
|
||||
|
||||
Here’s a walkthrough video showing some of the powerful capabilities of Nx Console:
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Nx Console meets Nx Cloud'
|
||||
slug: 'nx-console-meets-nx-cloud'
|
||||
authors: ['Max Kless']
|
||||
cover_image: '/blog/images/2023-01-18/1*Mkqkadhkk7DydWvPg5L0bA.png'
|
||||
cover_image: '/blog/images/2023-01-18/Mkqkadhkk7DydWvPg5L0bA.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -31,7 +31,7 @@ To follow along, ensure you have installed the latest Nx Console version:
|
||||
|
||||
In the Nx sidebar, you will see a new Nx Cloud section.
|
||||
|
||||
|
||||
|
||||
|
||||
If your workspace is not using Nx Cloud, click the “Set up Nx Cloud” button to set up the cloud runner automatically.
|
||||
|
||||
@ -59,15 +59,15 @@ You will see that some changes happen in your `nx.json`:
|
||||
|
||||
Let’s try it out! Select a task to run and see the results in the run list. You can get an even more detailed breakdown in the Nx Cloud web app.
|
||||
|
||||
|
||||
|
||||
|
||||
If you rerun the same task, you can see that the time it took to complete is under a second. This is because of Nx’s [advanced computation caching](/features/cache-task-results). Whenever a task is executed, Nx caches it. If the task has been run before, it just restores the result from the cache. By default, this cache is local to your own workstation. However, with Nx Cloud, you can distribute and share it between machines.
|
||||
|
||||
|
||||
|
||||
|
||||
To see it in action, push your newly created access token and have a coworker (or CI pipeline) run a task on their machine. If you execute that same task again, it will be pulled from the cache just like it did locally! 🔮
|
||||
|
||||
|
||||
|
||||
|
||||
To learn more about Nx Cloud access tokens, head over to the docs: [Access Tokens Documentation](/ci/recipes/security/access-tokens).
|
||||
|
||||
@ -75,7 +75,7 @@ To learn more about Nx Cloud access tokens, head over to the docs: [Access Token
|
||||
|
||||
If you’ve just started using Nx Cloud, you will probably see this message prompting you to claim your workspace:
|
||||
|
||||
|
||||
|
||||
|
||||
Out of the box, Nx Cloud works without the need to register. It is, however, highly recommended to create an account and associate it with your workspace. This process is called _claiming your workspace_ and has become much easier with Nx Console! After claiming, you can take full control of your cloud workspace, manage access restrictions and other settings.
|
||||
|
||||
@ -87,23 +87,23 @@ From now on, Nx Console will be able to make authenticated requests to the cloud
|
||||
|
||||
Distributed Task Execution (DTE) becomes very important as your workspace grows. With Nx, powerful features like [computation caching](http://√) and [affected analysis](/ci/features/affected) help you drastically cut down your CI times. Most of the time, large parts of your codebase will not need to be rebuilt and retested. However, we also have to consider the worst-case-scenarios. Let’s say you do change a core lib that everything in your monorepo depends on. This could mean hundreds or even thousands of projects needing to be rebuilt and retested, which would mean hours of CI time. This is obviously very impractical and you should consider solutions that allow you to parallelize all this work and keep worst-case CI times at a reasonable level. [There are different approaches to achieving this](/ci/concepts/parallelization-distribution) but it’s hard to get right and not something most teams want to spend engineering resources on.
|
||||
|
||||
|
||||
|
||||
|
||||
Distributed Task Execution with Nx Cloud solves this issue — it allows you to optimally parallelize tasks without thinking about their interdependencies or agent management. You don’t have to use it immediately, but it’s useful if you want to keep your CI times low even as your workspace grows. 🚀
|
||||
|
||||
DTE is available for all Nx Cloud workspaces with minimal setup. If you see a yellow DTE status in Nx Console, that just means you haven’t used it yet. [Check out the docs](/ci/features/distribute-task-execution) to [learn more about the motivation for DTE](/ci/concepts/parallelization-distribution) and [how to test it out in your workspace](/ci/features/distribute-task-execution).
|
||||
|
||||
|
||||
|
||||
|
||||
## VCS Integration
|
||||
|
||||
Nx Cloud isn’t just great for its remote caching and DTE features, it also generates readable and searchable reports for any executed tasks — whether it be 10 or 10.000. In a monorepo, your CI pipelines will seldom run just a single task. It’s more common to have commands like `nx affected — -target=build` which amounts to “rebuild everything that changed”. This could potentially be dozens, hundreds or thousands of tasks. If something goes wrong, combing through thousands upon thousands of lines of logs quickly becomes tedious. So having a nicely structured, per-target view that you can filter and sort while still preserving all terminal styling is incredibly useful!
|
||||
|
||||
|
||||
|
||||
|
||||
To take advantage of this valuable information without changing your development workflow, use the Nx Cloud integration for your favourite platform: Github, GitLab or Bitbucket Cloud. You can see the results of your cloud runs in a PR comment with an overview of failed tasks and links to easily readable outputs. No more scrolling through endless logs until you find what you need!
|
||||
|
||||
|
||||
|
||||
|
||||
To set it up, just click on the button in the Nx Console cloud view and follow the prompts in your browser. Read more in the [full guide on connecting your workspace to](/ci/recipes/set-up/monorepo-ci-github-actions) VCS.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Configuration Files and Potholes in Your Codebase'
|
||||
slug: 'configuration-files-and-potholes-in-your-codebase'
|
||||
authors: ['Isaac Mann']
|
||||
cover_image: '/blog/images/2023-01-31/0*T-xiDccBOxMQpDrG.png'
|
||||
cover_image: '/blog/images/2023-01-31/T-xiDccBOxMQpDrG.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -12,21 +12,21 @@ Let’s talk about configuration. The detractors call it boilerplate while propo
|
||||
|
||||
There have been many attempts over the years to make it easier to bypass configuration code.
|
||||
|
||||
|
||||
|
||||
|
||||
Ruby on Rails popularized the philosophy of Convention over Configuration. In this philosophy, the default configuration settings are derived from your folder structure or the way you name your files. These unwritten conventions are used as a way of bypassing writing configuration files that most of the time will follow a set pattern.
|
||||
|
||||
|
||||
|
||||
|
||||
Parcel advertises itself as a zero configuration bundler. This is mostly a reaction to webpack, which requires a fairly complex config file before it can do anything useful. As application grow more complex, so does the config file. These often become so complicated that developers dread fixing any problems with them, because once it becomes known that they have fixed a problem with webpack, they will be forever saddled with the burden of maintaining that file. In contrast, Parcel does all the tasks required of a typical SPA web app without any config file.
|
||||
|
||||
|
||||
|
||||
|
||||
Apple also leveraged this sentiment with marketing slogan “It Just Works”. Compared to Windows or Linux ecosystems that require modifying settings to get software from different companies to work together, Apple provides its own suite of tools and hardware that have a major selling point of being intentionally designed to all work together. Theoretically, any hardware or software produced by Apple should fit seamlessly into the rest of the system.
|
||||
|
||||
All of these efforts to skip the configuration step reach their limits at some point. The idea of hiding default configuration works well, until you need to modify that default and have no starting point. The Zen of Python philosophy of “explicit is better than implicit” is a direct contradiction to Convention over Configuration. If you like most of what the zero config tool gives you, but you want to tweak it a little bit, it can be hard to find where to do the tweaking. Apple is great when It Just Works. But sometimes, It Just Doesn’t.
|
||||
|
||||
|
||||
|
||||
|
||||
## How much configuration is the right amount of configuration?
|
||||
|
||||
@ -42,7 +42,7 @@ The problem with both of these tools is that any code they generate for you is i
|
||||
|
||||
## Nx Generators and Migration Generators
|
||||
|
||||
|
||||
|
||||
|
||||
Nx has an elegant solution to this dilemma. There are three key parts.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Setup React and Tailwind — The Easy Way'
|
||||
slug: 'setup-react-and-tailwind-the-easy-way'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2023-02-09/1*TK4Kdj-cc890gQkgUtKNyA.png'
|
||||
cover_image: '/blog/images/2023-02-09/TK4Kdj-cc890gQkgUtKNyA.png'
|
||||
tags: [nx, tutorial]
|
||||
---
|
||||
|
||||
@ -16,7 +16,7 @@ Developers love to argue about whether Tailwind is good, almost like arguing abo
|
||||
|
||||
Tailwind has good docs around getting started quickly. There are options to set up Tailwind with their Tailwind CLI, PostCSS, and framework-specific guides.
|
||||
|
||||
|
||||
|
||||
|
||||
These steps mostly involve
|
||||
|
||||
@ -26,7 +26,7 @@ These steps mostly involve
|
||||
|
||||
**One important thing:** if you use [Create-React-App](https://create-react-app.dev/) you might want to check out [what the Tailwind docs say](https://tailwindcss.com/docs/guides/create-react-app) first.
|
||||
|
||||
|
||||
|
||||
|
||||
This came up a couple of weeks ago due to a [PR opened on the CRA repo](https://github.com/reactjs/reactjs.org/pull/5487) asking to kinda deprecate it as the main choice for new React projects. I couldn’t help but share my opinion on this as well:
|
||||
|
||||
@ -44,7 +44,7 @@ Nx has such generators. To use them, you need an Nx-based React setup. If you’
|
||||
$ npx create-nx-workspace reactapp --preset=react-standalone
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
As you can see, this allows you to choose which bundler to use as well as other options (such as the CSS setup). Again, this is already such a code generator that creates this initial project scaffold.
|
||||
|
||||
@ -72,7 +72,7 @@ You’ll get
|
||||
- Tailwind configured together with PostCSS
|
||||
- your main `styles.css` file updated with the Tailwind base classes
|
||||
|
||||
|
||||
|
||||
|
||||
## That’s it!
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Nx 15.7 — Node Support, Angular LTS, Lockfile Pruning'
|
||||
slug: 'nx-15-7-node-support-angular-lts-lockfile-pruning'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2023-02-16/1*2AAo-mng7QyJP9yC80zNFQ.png'
|
||||
cover_image: '/blog/images/2023-02-16/2AAo-mng7QyJP9yC80zNFQ.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -29,7 +29,7 @@ Here’s all you need to know about our latest Nx release.
|
||||
|
||||
It’s almost a tradition to have some stats at the beginning of our Nx release blog posts. This time, about our YT channel: incredibly, we crossed 10k subscribers [on our Youtube channel](https://www.youtube.com/@nxdevtools)!!
|
||||
|
||||
|
||||
|
||||
|
||||
Apart from delivering high-quality engineering work, we’re very invested in producing educational content around developer tooling and monorepos. We’ve been almost consistently shipping new content every week, whether that is blog posts on the [Nx blog](/blog) or in the form of new videos and live streams on our channel. Seeing our audience grow on Youtube confirms we’re on the right track and gives us new fuel to keep pushing!!
|
||||
|
||||
@ -48,7 +48,7 @@ Please have a look at our updated guide: [/extending-nx/tutorials/organization-s
|
||||
Due to a lack of time we never invested much more into streamlining the Node experience within Nx, though. This [changed now](/blog/from-bootstrapped-to-venture-backed), which is why we’re committed to making Nx the best developer tool for node based apps. Starting with v15.7 we improved support for [ExpressJS](https://expressjs.com/), [Fastify](https://fastify.io/) and [Koa](https://koajs.com/).
|
||||
When starting a new Nx workspace, you now have a new option: “Standalone Node Server app”.
|
||||
|
||||
|
||||
|
||||
|
||||
This is when you want a single-project Nx workspace to build out your Node backend.
|
||||
|
||||
@ -142,13 +142,13 @@ You can try out Storybook 7.0 beta in a new Nx workspace by passing the `--story
|
||||
|
||||
Previously when you created a new React application with the Nx `@nrwl/react` plugin, the actual Webpack config was hidden within the plugin itself.
|
||||
|
||||
|
||||
|
||||
|
||||
It was for a good reason, but at the same time, it is a thin line to walk between giving more flexibility and ensuring integrity and consistency (not to speak about features such as [automated code migrations](/features/automate-updating-dependencies)). We wrote a [blog post about it last week](/blog/configuration-files-and-potholes-in-your-codebase).
|
||||
|
||||
Inspired by our new [Vite setup](/nx-api/vite), which allows for a more modular configuration in the `vite.config.ts`, we wanted to bring some of the same flexibility to our Webpack setup as well. As such, now every Nx Webpack setup (e.g. a new React + Webpack based app) have a `webpack.config.js` in the project root. Old project are automatically migrated to this new setup.
|
||||
|
||||
|
||||
|
||||
|
||||
If you want to upgrade but still retain the previous behavior, we introduced an `isolatedConfig` mode that can be set to `false`. More details on our docs: [/recipes/webpack/webpack-config-setup](/recipes/webpack/webpack-config-setup)
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Using NgRx Standalone APIs with Nx'
|
||||
slug: 'using-ngrx-standalone-apis-with-nx'
|
||||
authors: ['Colum Ferry']
|
||||
cover_image: '/blog/images/2023-02-21/1*pJHhA04d6jIjOb5vpCDjyw.png'
|
||||
cover_image: '/blog/images/2023-02-21/pJHhA04d6jIjOb5vpCDjyw.png'
|
||||
tags: [nx, tutorial]
|
||||
---
|
||||
|
||||
@ -30,7 +30,7 @@ Select:
|
||||
|
||||
The result should look something like this:
|
||||
|
||||
|
||||
|
||||
|
||||
Now run `cd myorg` to enter the workspace.
|
||||
|
||||
@ -64,7 +64,7 @@ You’ll be asked for a name for the feature state, but you can ignore this and
|
||||
|
||||
Say false to Facades also.
|
||||
|
||||
|
||||
|
||||
|
||||
The generator will now make changes to your `main.ts` file and install the NgRx packages for you!
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'What’s New With Lerna 6.5?'
|
||||
slug: 'whats-new-with-lerna-6-5'
|
||||
authors: ['Zack DeRose']
|
||||
cover_image: '/blog/images/2023-02-22/1*izlWzEYnkZ9myXi58Rmv8A.png'
|
||||
cover_image: '/blog/images/2023-02-22/izlWzEYnkZ9myXi58Rmv8A.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -27,7 +27,7 @@ You can find a more detailed account of Lerna’s “Maintainance Odyssey” in
|
||||
|
||||
Since Nx took over in Lerna 4, we’ve added a brand new site to refresh the Lerna Docs:
|
||||
|
||||
|
||||
|
||||
|
||||
The top of our priorities for Lerna 5 was to resolve all vulnerabilities and outdated dependencies facing Lerna. We went on to make Lerna faster by allowing users to [opt into Nx’s task caching inside of Lerna with the new `lerna add-caching` command](https://github.com/lerna/lerna/tree/main/packages/lerna/src/commands/add-caching#readme), and [add support for distributed caching to share task results amongst your organization in Lerna with Nx Cloud](https://lerna.js.org/docs/features/share-your-cache).
|
||||
|
||||
@ -41,7 +41,7 @@ We’ve also started an initiative to assist Open Source projects in getting the
|
||||
|
||||
We’ve just started this initiative and have already been able to help [Sentry](https://github.com/getsentry/sentry-javascript) get optimized with task caching and task pipeline optimizations for their workspace!
|
||||
|
||||
|
||||
|
||||
|
||||
This initiative complements [our free tier of unlimited Nx Cloud](/pricing) for any Open Source project.
|
||||
|
||||
@ -95,8 +95,8 @@ You can find more information on this change [here](https://github.com/lerna/ler
|
||||
|
||||
Unlike the other updates mentioned for 6.5, this update does not affect Lerna’s public API, but as you can see from the numbers, this was quite an undertaking:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The result is a significant improvement to the Typescript support for Lerna’s internals and a substantial simplification of the codebase. This investment will make Lerna significantly more approachable to other would-be contributors!
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Bundling a Node API with Fastify, esbuild, and Nx'
|
||||
slug: 'bundling-a-node-api-with-fastify-esbuild-and-nx'
|
||||
authors: ['Jack Hsu']
|
||||
cover_image: '/blog/images/2023-02-28/1*PADY_RKrkXj39p4nj79ESw.png'
|
||||
cover_image: '/blog/images/2023-02-28/PADY_RKrkXj39p4nj79ESw.png'
|
||||
tags: [nx, tutorial]
|
||||
---
|
||||
|
||||
@ -170,7 +170,7 @@ To build the image, run `npx nx docker-build`. The image copies only the self-co
|
||||
|
||||
Nx is smart enough to bundle the app before building the Docker image — because of the `dependsOn` configuration in `project.json`. You can visualize this dependency with `npx nx graph`.
|
||||
|
||||
|
||||
|
||||
|
||||
Now that the image is built, we can run it.
|
||||
|
||||
@ -218,11 +218,11 @@ $ fly deploy
|
||||
|
||||
Fly will log out the monitoring link when the app is successfully deployed.
|
||||
|
||||
|
||||
|
||||
|
||||
And you can open the deployed server using `fly open`.
|
||||
|
||||
|
||||
|
||||
|
||||
That’s it! Our server is now deployed for the world to use.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Expanding Nx Console to JetBrains IDEs'
|
||||
slug: 'expanding-nx-console-to-jetbrains-ides'
|
||||
authors: ['Max Kless']
|
||||
cover_image: '/blog/images/2023-03-02/1*lEAhfd3d17hGichyT-oGbw.png'
|
||||
cover_image: '/blog/images/2023-03-02/lEAhfd3d17hGichyT-oGbw.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -17,7 +17,7 @@ Go grab it on the official store.
|
||||
👉 **Install link:
|
||||
** [https://plugins.jetbrains.com/plugin/21060-nx-console](https://plugins.jetbrains.com/plugin/21060-nx-console)
|
||||
|
||||
|
||||
|
||||
|
||||
Before we go into details of Nx Console for IntelliJ, we’d really want to go and **thank our community**. [\* \*_Issam Guissouma_\*\*](https://twitter.com/iguissouma) and [**_Edward Tkachev_**](https://twitter.com/etkachev) from the
|
||||
Nx community had their own Nx Console plugins for IntelliJ out there already for a while. And they have been super
|
||||
@ -124,7 +124,7 @@ without the core support.
|
||||
|
||||
## Generate UI
|
||||
|
||||
|
||||
|
||||
_Screenshot of the generate UI in IntelliJ_
|
||||
|
||||
As mentioned, the generate UI is a key feature of Nx Console. It allows users to easily generate code by using a
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Nx 15.8 — Rust Hasher, Nx Console for IntelliJ, Deno, Node and Storybook'
|
||||
slug: 'nx-15-8-rust-hasher-nx-console-for-intellij-deno-node-and-storybook'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2023-03-08/1*2gKrC6_Yx3hVkQaHxnw5xw.png'
|
||||
cover_image: '/blog/images/2023-03-08/2gKrC6_Yx3hVkQaHxnw5xw.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -138,7 +138,7 @@ Read all the details [on our blog post](/blog/expanding-nx-console-to-jetbrains-
|
||||
|
||||
Nx Console has proven a highly valuable tool for exploring Nx generators. Especially if you cannot recall all the various parameters, you can possibly pass. And sure, you could always pass the `--help` or browse [the docs](/nx-api/react/generators/library), but it is just less convenient.
|
||||
|
||||
|
||||
|
||||
|
||||
With a growing number of parameters that a generator can take, it started to get messy and overwhelming. Furthermore, in 80% of the cases, you would probably need the main parameters such as the name, bundler, and directory where to generate the output.
|
||||
This is the main reason we introduced a `x-priority` flag to our generator metadata, to have a way to prioritize certain flags and show them more prominently to the end user. Available values are `important` and `internal`.
|
||||
@ -157,7 +157,7 @@ The property can be defined for the desired parameters in the generator’s `sch
|
||||
|
||||
All required properties and those marked with an `x-priority: important` will be shown at the top of both, the CLI output (when using `--help`) as well as the Nx Console UI.
|
||||
|
||||
|
||||
|
||||
|
||||
Read all about it [in the doc about Customizing Generator Options](/extending-nx/recipes/generator-options).
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Rspack — Getting up to speed with Nx'
|
||||
slug: 'rspack-getting-up-to-speed-with-nx'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2023-03-10/1*fWQ53mw2itEs3SGAOJVonQ.png'
|
||||
cover_image: '/blog/images/2023-03-10/fWQ53mw2itEs3SGAOJVonQ.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Nx 16 is Here!'
|
||||
slug: 'nx-16-is-here'
|
||||
authors: ['Zack DeRose']
|
||||
cover_image: '/blog/images/2023-05-02/1*n8JTIcKSYkebBOl8zZuF9w.png'
|
||||
cover_image: '/blog/images/2023-05-02/n8JTIcKSYkebBOl8zZuF9w.png'
|
||||
youtubeUrl: 'https://youtu.be/JIhOyJtuxEA'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Introducing the Nx Champions Program'
|
||||
slug: 'introducing-the-nx-champions-program'
|
||||
authors: ['Isaac Mann']
|
||||
cover_image: '/blog/images/2023-05-16/0*cVGLh0H-uOpy7-D6.png'
|
||||
cover_image: '/blog/images/2023-05-16/cVGLh0H-uOpy7-D6.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -16,7 +16,7 @@ Champion is both a noun and a verb and the champion in Nx Champions is intended
|
||||
|
||||
A full list of Nx Champions is available at [/community](/community).
|
||||
|
||||
|
||||
|
||||
_List of Nx Champions_
|
||||
|
||||
We appreciate everyone who was part of the initial group of Nx Champions, but acknowledge that there are more people who could qualify. If you are interested in joining the program, fill out the [application form](https://forms.gle/wYd9mC3ka64ki96G7) and let’s talk about it.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Determine your User Location with Netlify Edge Functions'
|
||||
slug: 'determine-your-user-location-with-netlify-edge-functions'
|
||||
authors: ['Nicholas Cunningham']
|
||||
cover_image: '/blog/images/2023-05-26/1*G2ynKDm6DIKLcZ2fJlV0dw.png'
|
||||
cover_image: '/blog/images/2023-05-26/G2ynKDm6DIKLcZ2fJlV0dw.png'
|
||||
tags: [nx, tutorial]
|
||||
---
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Introducing Nx Ecosystem CI'
|
||||
slug: 'introducing-nx-ecosystem-ci'
|
||||
authors: ['Katerina Skroumpelou']
|
||||
cover_image: '/blog/images/2023-06-20/1*EffyLKcVe5gE_x3MT8PJUQ.png'
|
||||
cover_image: '/blog/images/2023-06-20/EffyLKcVe5gE_x3MT8PJUQ.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Nx 16.5 Release!!!'
|
||||
slug: 'nx-16-5-release'
|
||||
authors: ['Zack DeRose']
|
||||
cover_image: '/blog/images/2023-07-06/1*Gm3s_wLWrAf_uH2AzfJvvQ.png'
|
||||
cover_image: '/blog/images/2023-07-06/Gm3s_wLWrAf_uH2AzfJvvQ.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -30,7 +30,7 @@ There’s also built-in support for the new turbopack builder option via the `--
|
||||
|
||||
We’ve also launched a new preset for `npx create-nx-workpace` for a standalone NextJS app. Checkout it out using the command: `npx create-nx-workspace@latest --preset=nextjs-standalone` or use the interactive prompts to find it:
|
||||
|
||||
|
||||
|
||||
|
||||
We’ve added a couple videos specifically on Next development in an Nx workspace in the past month, so if you’re looking for more on Next, be sure to check them out!
|
||||
|
||||
@ -198,9 +198,9 @@ You can see our results and the details of the benchmark — and even run the be
|
||||
|
||||
Nx Console got a new coat of paint in both the VsCode and JetBrains (IntelliJ/Webstorm) IDEs!
|
||||
|
||||
|
||||
|
||||
_New Nx Console Coat of Paint in VsCode_
|
||||
|
||||
|
||||
_New Nx Console Coat of Paint in IntelliJ_
|
||||
|
||||
As part of the redesign, we also moved our webviews to the Lit framework — checkout all the latest updates in this video:
|
||||
@ -211,7 +211,7 @@ As part of the redesign, we also moved our webviews to the Lit framework — che
|
||||
|
||||
Last but CERTAINLY not least, we’ve launched [a new changelog](/changelog) to our docs site!
|
||||
|
||||
|
||||
|
||||
|
||||
This changelog includes links to all the release notes for all major and minor versions, as well as links to patch versions. We made sure to also include any deprecations or breaking changes brought about by each version as well.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Evergreen Tooling — More than Just CodeMods'
|
||||
slug: 'evergreen-tooling-more-than-just-codemods'
|
||||
authors: ['Juri Strumpflohner']
|
||||
cover_image: '/blog/images/2023-07-26/1*CPiI60mSguYXJzPfAHMbEQ.png'
|
||||
cover_image: '/blog/images/2023-07-26/CPiI60mSguYXJzPfAHMbEQ.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -42,7 +42,7 @@ Updating tooling is never easy, but the Nx team aims at making it “easier” a
|
||||
|
||||
The “why” is pretty straightforward. From the perspective of an open-source project, you want users to adopt the latest version as quickly as possible. This minimizes the maintenance work involved in supporting older versions, which can be a real headache. Looking at how Nx manages it, it seems to be successful in this regard ([Source](https://www.craigory.dev/npm-burst/?package=nx)):
|
||||
|
||||
|
||||
|
||||
|
||||
The distribution of Nx installs by version demonstrates the effectiveness of this approach. For instance, v16.5, which accounts for 19.7% of all versions, has already been adopted by many users, despite [its recent release](/changelog). The latest major accounts for 34.7% already and 41.4% are on the previous v15, a large majority of which is on the latest 15.9 minor. Hence, v16 & v15 make up 3/4 of all Nx installs.
|
||||
|
||||
@ -145,7 +145,7 @@ It leverages the utility functions provided by the `@nx/devkit` package to read
|
||||
|
||||
Nx’s modular design helps as each plugin is responsible for a particular area and can thus contribute according migration scripts. To give you some context. There is the [nx package](https://www.npmjs.com/package/nx) at the core — which you can use nicely in combination with a [PNPM workspaces repo](/blog/setup-a-monorepo-with-pnpm-workspaces-and-speed-it-up-with-nx) to speed things up — and then there are plugins built on top.
|
||||
|
||||
|
||||
|
||||
|
||||
_(Source:_ [_/getting-started/why-nx_](/getting-started/why-nx)_)_
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Storybook Interaction Tests in Nx'
|
||||
slug: 'storybook-interaction-tests-in-nx'
|
||||
authors: ['Katerina Skroumpelou']
|
||||
cover_image: '/blog/images/2023-08-03/1*NfJA7VBZvDwyyZHmV8qsiw.png'
|
||||
cover_image: '/blog/images/2023-08-03/NfJA7VBZvDwyyZHmV8qsiw.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -38,7 +38,7 @@ For complex flows, it can be worthwhile to group sets of related interactions us
|
||||
|
||||
Storybook provides an interactive debugger that displays the step-by-step flow of your interactions, and provides UI controls to pause, resume, rewind, and step through each interaction.
|
||||
|
||||
|
||||
|
||||
_Interaction test for the click of a button._
|
||||
|
||||
If an error occurs during a story’s play function, it’ll be shown in the interaction addon panel to help with debugging. And since Storybook is a web app, anyone with the URL can reproduce the error with the same detailed information without any additional environment configuration or tooling required.
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Create Your Own create-react-app CLI'
|
||||
slug: 'create-your-own-create-react-app-cli'
|
||||
authors: ['Emily Xiong']
|
||||
cover_image: '/blog/images/2023-08-10/1*j2QU-hjxt-1krFST8CGFiA.png'
|
||||
cover_image: '/blog/images/2023-08-10/j2QU-hjxt-1krFST8CGFiA.png'
|
||||
tags: [nx]
|
||||
---
|
||||
|
||||
@ -47,7 +47,7 @@ Note, if you already have an existing Nx plugin workspace, instead of creating a
|
||||
nx g @nx/plugin:create-package <cli name> --project=<existing plugin name> --e2eProject e2e
|
||||
```
|
||||
|
||||
|
||||
|
||||
_Project graph of the workspace_
|
||||
|
||||
The resulting workspace contains 2 projects: a CLI and an Nx plugin.
|
||||
@ -59,7 +59,7 @@ The resulting workspace contains 2 projects: a CLI and an Nx plugin.
|
||||
|
||||
Let’s focus on the `create-my-own-react-app` project which is our CLI.
|
||||
|
||||
|
||||
|
||||
|
||||
The `index.ts` file is the key part here. It is the one that gets invoked when someone runs `npx create-my-own-react-app` later once we publish it.
|
||||
|
||||
@ -121,7 +121,7 @@ _(Note,_ `_publish_` _is a target defined in the_ `_project.json_` _of our proje
|
||||
|
||||
This command will publish both `my-own-react` and `create-my-own-react-app` packages to your local registry. If open the running Verdaccio registry at [http://localhost:4873](http://localhost:4873) you should see the published packages.
|
||||
|
||||
|
||||
|
||||
|
||||
3\. Now, you can run `npx create-my-own-react-app` just like a developer using our CLI would. For example, go to the tmp directory and create a `my-own-react` workspace named `test`:
|
||||
|
||||
@ -132,7 +132,7 @@ npx create-my-own-react-app@1.0.0 test
|
||||
|
||||
What you’ll get is an Nx workspace with the base setup and a `test` library project with a single TS file. Because that’s exactly what our current `preset` generator does.
|
||||
|
||||
|
||||
|
||||
|
||||
Let’s fix that in the next step.
|
||||
|
||||
@ -184,7 +184,7 @@ The preset generator does 2 things:
|
||||
- Generates files in the project using the`generateFiles` function. This uses the templates under `src/generators/preset/files` which are interpolated to become the files that are generated for the user.
|
||||
- Format the generated files with `prettier` with the`formatFiles` function
|
||||
|
||||
|
||||
|
||||
_preset generator_
|
||||
|
||||
The `addProjectConfiguration` and `generateFiles` functions are from [@nx/devkit](/nx-api/devkit/documents/nx_devkit), a library that contains utility functions for writing plugins for Nx. For the future, see the [complete list of utility functions](/nx-api/devkit/documents/nx_devkit).
|
||||
@ -393,7 +393,7 @@ npx create-my-own-react-app@1.0.1 test2
|
||||
|
||||
The CLI now creates a workspace with the dependencies we want and the code for the react application just like `create-react-app`:
|
||||
|
||||
|
||||
|
||||
|
||||
## Step 5: Add a Serve Target
|
||||
|
||||
@ -472,15 +472,15 @@ npx nx run-many --targets publish --ver 1.0.2 --tag latest
|
||||
|
||||
Once we generate a new workspace with the new preset version (npx create-my-own-react-app@1.0.2 test3), we should now see our `package.json` `start`script being generated.
|
||||
|
||||
|
||||
|
||||
|
||||
To run the app we either run
|
||||
|
||||
- `npm start`
|
||||
- or `npx nx start` which would automatically pick up the `start` script in the `package.json`
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
_serve output_
|
||||
|
||||
## Step 7: Add a Prompt to the CLI to Customize the Starter App
|
||||
@ -576,8 +576,8 @@ Also, change the CSS for `.App-header` in the CSS template file`src/generators/p
|
||||
|
||||
Now if you republish the projects and regenerate an app with the light mode, you should see the background color and text color of the header got changed:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
_serve output_
|
||||
|
||||
## Step 8: E2E Testing
|
||||
|
||||
@ -2,14 +2,14 @@
|
||||
title: 'Step-by-Step Guide to Creating an Expo Monorepo with Nx'
|
||||
slug: 'step-by-step-guide-to-creating-an-expo-monorepo-with-nx'
|
||||
authors: ['Emily Xiong']
|
||||
cover_image: '/blog/images/2023-08-24/1*IpM0kZdUNXoDWV4r8J5xXQ.png'
|
||||
cover_image: '/blog/images/2023-08-24/IpM0kZdUNXoDWV4r8J5xXQ.png'
|
||||
tags: [nx, tutorial]
|
||||
---
|
||||
|
||||
This blog will show you how to create an Expo monorepo with Nx. In this example, you will be creating two Expo apps in a monorepo with `@nx/expo`: one shows random facts about cats, and the other shows random facts about dogs.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
_Left: cats, right: dogs_
|
||||
|
||||
As shown in the above screenshots, these two apps have the same branding and reuse all components.
|
||||
@ -42,7 +42,7 @@ This will create an [integrated](/deprecated/integrated-vs-package-based) repo.
|
||||
|
||||
Now, your Nx workspace should have cats and cats-e2e under the `apps` folder and an empty libs folder:
|
||||
|
||||
|
||||
|
||||
|
||||
### Existing Nx Workspace
|
||||
|
||||
@ -67,7 +67,7 @@ npx nx generate @nx/expo:app cats
|
||||
|
||||
Alternatively, if you use Visual Studio Code as your code editor, you can also create apps using [Nx Console](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console):
|
||||
|
||||
|
||||
|
||||
|
||||
## Install Tech Stacks
|
||||
|
||||
@ -109,7 +109,7 @@ npx nx generate @nx/expo:lib ui
|
||||
|
||||
Now under the `libs` folder, a `ui` folder has been created:
|
||||
|
||||
|
||||
|
||||
_ui folder_
|
||||
|
||||
To create a component in the `ui` library, run:
|
||||
@ -120,7 +120,7 @@ npx nx generate @nx/expo:component carousel --project=ui --export
|
||||
|
||||
You can see that a `carousel` folder has been created in the `libs/ui/src/lib` folder:
|
||||
|
||||
|
||||
|
||||
_carousel folder_
|
||||
|
||||
Next, modify this component to display the content with props passed in:
|
||||
@ -190,7 +190,7 @@ export default App;
|
||||
|
||||
Run the app with`nx start cats`, and you should be able to see the app on the simulator:
|
||||
|
||||
|
||||
|
||||
_Page on the simulator (left: iOS, right: Android)_
|
||||
|
||||
## Add Another App
|
||||
@ -203,11 +203,11 @@ npx nx generate @nx/expo:app dogs
|
||||
|
||||
Alternatively, if you use Visual Studio Code as your code editor, you can also create apps using [Nx Console](https://marketplace.visualstudio.com/items?itemName=nrwl.angular-console):
|
||||
|
||||
|
||||
|
||||
|
||||
Under the apps folder, there should be `cats/`, `dogs/` and their e2es.
|
||||
|
||||
|
||||
|
||||
_apps folder_
|
||||
|
||||
You can reuse the UI library in the Dogs app in `apps/dogs/src/app/App.tsx` with the below code:
|
||||
@ -285,7 +285,7 @@ npx nx build cats --profile=preview
|
||||
|
||||
You can view your build status at [https://expo.dev/](https://expo.dev/):
|
||||
|
||||
|
||||
|
||||
|
||||
If you want to create a build locally using your own infrastructure:
|
||||
|
||||
@ -316,7 +316,7 @@ You can manually upload the build bundle binary to the app store, or you can sub
|
||||
|
||||
First, in `app.json` under the project `apps/cats/app.json`, you need to make sure`ios.bundleIdentifier` and `android.package` keys are correct:
|
||||
|
||||
|
||||
|
||||
_app.json_
|
||||
|
||||
To submit your app to the app stores, run:
|
||||
@ -327,7 +327,7 @@ npx nx submit cats
|
||||
|
||||
Nx will prompt you to choose the platform to which you want to submit:
|
||||
|
||||
|
||||
|
||||
|
||||
Or you can also specify the platform directly in the initial command:
|
||||
|
||||
@ -346,7 +346,7 @@ It will then ask you to choose which binary to submit from one of the following
|
||||
|
||||
Alternatively, you can submit your app on the [expo.dev](https://expo.dev/) site. Go to your build, under options, choose “Submit to an app store”:
|
||||
|
||||
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Nx 16.8 Release!!!'
|
||||
slug: 'nx-16-8-release'
|
||||
authors: ['Zack DeRose']
|
||||
cover_image: '/blog/images/2023-09-06/1*16gTRcKon8B4IKYQAY9V8w.png'
|
||||
cover_image: '/blog/images/2023-09-06/16gTRcKon8B4IKYQAY9V8w.png'
|
||||
tags: [nx, release]
|
||||
---
|
||||
|
||||
@ -22,7 +22,7 @@ Be sure to checkout our livestream with Jay Bell (Nx Champion, former Nx Communi
|
||||
|
||||
Nx is also coming up on 20k Github stars [please help us get there!](https://github.com/nrwl/nx)
|
||||
|
||||
|
||||
|
||||
|
||||
**Table of Contents**
|
||||
· [NEW PROJECT GENERATOR BEHAVIOR: Project Creation Paths and Names in Nx Generators](#new-project-generator-behavior-project-creation-paths-and-names-in-nx-generators)
|
||||
@ -51,14 +51,14 @@ We also simplified the definition of Nx projects to be any directory that had a
|
||||
|
||||
With Nx 16.8, we’re introducing an all-new option in this `workspaceLayout` category: `projectNameAndRootFormat` where you can chose either the option to apply project names `as-provided` or `derived`.
|
||||
|
||||
|
||||
|
||||
|
||||
If you don’t set this option in your `nx.json` file, our generators will now prompt you as to how we should set:
|
||||
|
||||
- the name of your project (as in the project’s `project.json` file)
|
||||
- where to put the project in your filesystem
|
||||
|
||||
|
||||
|
||||
|
||||
You can avoid the extra prompt above by setting the `projectNameAndRootFormat` in the `workspaceLayout` category of your `nx.json` file, or by providing it in in your generate command:
|
||||
|
||||
@ -199,7 +199,7 @@ We wanted to make it transparent though and not something the user needs to worr
|
||||
|
||||
When enabling batch mode, Nx leverages the underlying [project graph](/features/explore-graph) to generate TypeScript project references behind the scenes for you, to fully leverage TS incremental building. The results are amazing. According to [our benchmarks](https://github.com/nrwl/large-ts-monorepo), batch mode has the potential to speed up Typescript compilation by up to 5x for large monorepos.
|
||||
|
||||
|
||||
|
||||
|
||||
In addition to batch mode, the processing of Typescript dependencies is **now using a faster and more accurate Rust implementation**. This should be transparent to most users — aside from your monorepo becoming even faster!
|
||||
|
||||
@ -207,13 +207,13 @@ In addition to batch mode, the processing of Typescript dependencies is **now us
|
||||
|
||||
A new Nx plugin has appeared!!
|
||||
|
||||
|
||||
|
||||
|
||||
Nx now supports Playwright as an e2e option alongside our long-standing support for Cypress!
|
||||
|
||||
First off, this means we’ve added Playwright as an option when generating new frontend applications:
|
||||
|
||||
|
||||
|
||||
|
||||
If you want to add playwright to an existing project in your workspace you can also do that now by installing the plugin (here using `npm`):
|
||||
|
||||
@ -245,27 +245,27 @@ If you’re not familiar — Nx Console is our IDE enhancement for [VsCode (1.4
|
||||
|
||||
Nx Console provides a Graphical User Interface for running tasks and generating code for your Nx Monorepos, and it also provides the ability to view your project graph
|
||||
|
||||
|
||||
|
||||
|
||||
and task graph
|
||||
|
||||
|
||||
|
||||
|
||||
within your IDE!
|
||||
|
||||
As of our latest release, Nx Console has added the new feature of adding buttons inside the project graph to take you directly to the selected project in the project graph:
|
||||
|
||||
|
||||
|
||||
|
||||
And gives you a “play button” to run any task within your task graph:
|
||||
|
||||
|
||||
|
||||
|
||||
## ENHANCEMENT: Storybook Support for Interaction Testing
|
||||
|
||||
Storybook 7 introduces new [Interaction Testing](https://storybook.js.org/getting-started/intro/react/writing-tests/interaction-testing) to their platform!
|
||||
|
||||
|
||||
|
||||
|
||||
The Nx Storybook plugin has now been enhanced with a new `interactionTests` option on the `storybook-configuration` generator, that will automate setting up these interaction tests for you when you use Nx to generate stories for your components!
|
||||
|
||||
@ -297,13 +297,13 @@ One of the great things about Nx is the extensibility, and the wide range of plu
|
||||
|
||||
Our docs site has hosted [a registry of these plugins](/plugin-registry) for awhile now, but we’ve recently added npm downloads, github stars, release dates, and compatible Nx versions to this registry:
|
||||
|
||||
|
||||
|
||||
|
||||
We expect that these will be valuable signals to users as to the quality of the plugin.
|
||||
|
||||
We’ve also added the ability to sort the registry by these metrics as a way of surfacing the higher quality plugins to the top!
|
||||
|
||||
|
||||
|
||||
|
||||
Go [check it out now](/plugin-registry) live on our docs site!
|
||||
|
||||
@ -317,13 +317,13 @@ We improved the messaging around Nx and more prominently emphasizing the [core f
|
||||
|
||||
The core part of the intro page now has a dedicated section for “Learning Nx”, surfacing some of our Nx, Nx Cloud and Monorepo videos as well as our in-depth tutorial about monorepos and single-project Nx workspaces. And we already have more in the works, so stay tuned.
|
||||
|
||||
|
||||
|
||||
|
||||
We’re also proud of all the new examples we’ve added in the last months. We have a brand new [Nx Recipe](https://github.com/nrwl/nx-recipes) repo with a variety of example projects that showcase Nx in combination with different technologies, even outside the JS ecosystem (e.g. with Rust, Go and .Net).
|
||||
|
||||
Go pick the ones you’re most interested in!
|
||||
|
||||
|
||||
|
||||
|
||||
You can find all of the examples and more on our “Showcase” section: [/showcase](/showcase).
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 'Introducing Playwright Support for Nx'
|
||||
slug: 'introducing-playwright-support-for-nx'
|
||||
authors: ['Emily Xiong']
|
||||
cover_image: '/blog/images/2023-09-18/1*_589bVpPTJ4D4IACBePXWQ.png'
|
||||
cover_image: '/blog/images/2023-09-18/589bVpPTJ4D4IACBePXWQ.png'
|
||||
tags: [nx, release, tutorial]
|
||||
---
|
||||
|
||||
@ -67,12 +67,12 @@ await page.getByTestId('submit-button').click();
|
||||
|
||||
Playwright creates a nice HTML test report that allows filtering tests by browsers, passed tests, failed tests, skipped tests, and flaky tests.
|
||||
|
||||
|
||||
|
||||
_HTML Test Report_
|
||||
|
||||
Clicking on the individual test shows more detailed errors along with each step of the test:
|
||||
|
||||
|
||||
|
||||
_Test error_
|
||||
|
||||
It also has other features like recording [screenshots](https://playwright.dev/docs/screenshots) and [videos](https://playwright.dev/docs/videos), [test generation](https://playwright.dev/docs/codegen), and [visual comparisons](https://playwright.dev/docs/test-snapshots). Read more about Playwright at [https://playwright.dev](https://playwright.dev/)
|
||||
@ -98,7 +98,7 @@ npx create-nx-workspace
|
||||
|
||||
We get a standalone Nx React app named `nx-react-playwright`:
|
||||
|
||||
|
||||
|
||||
_nx repo created_
|
||||
|
||||
What is a [standalone application](/deprecated/integrated-vs-package-based)? It is like an integrated monorepo setup but with just a single, root-level application. The repo has the same file structure as an app created from Create-React-App, but we can still leverage all the generators and executors and structure your application into libraries or submodules.
|
||||
@ -119,7 +119,7 @@ test('has title', async ({ page }) => {
|
||||
|
||||
The test verifies the `h1` header contains the text `Welcome`:
|
||||
|
||||
|
||||
|
||||
_Page served up_
|
||||
|
||||
To run the e2e tests, run the below command:
|
||||
@ -141,13 +141,13 @@ To open last HTML report run:
|
||||
|
||||
So the test passed and it also generated a report at `dist/.playwright/e2e/playwright-report/index.html`:
|
||||
|
||||
|
||||
|
||||
|
||||
### Add Another Test
|
||||
|
||||
Let's add another test to check the Documentation button works:
|
||||
|
||||
|
||||
|
||||
_Documentation_
|
||||
|
||||
In `src/app/nx-welcome.tsx`, we need to add a test id to the link:
|
||||
@ -208,7 +208,7 @@ For this example, I am going to add Playwright e2e tests to this repo: [nrwl/nx-
|
||||
|
||||
We are going to focus on the cart app in this example. In the terminal, run `npx nx serve cart` and it should serve up the app at [http://localhost:4200/cart](http://localhost:4200/cart).
|
||||
|
||||
|
||||
|
||||
_Cart App_
|
||||
|
||||
### Install @nx/playwright
|
||||
@ -244,7 +244,7 @@ It adds:
|
||||
- an e2e folder at `apps/cart/e2e` containing e2e tests
|
||||
- `playwright.config.ts` containing Playwright configuration
|
||||
|
||||
|
||||
|
||||
_new cart folder_
|
||||
|
||||
Let's update the default test `apps/cart/e2e/example.spec.ts` to check whether the header exists:
|
||||
@ -267,7 +267,7 @@ The second way is to create a separate E2E project folder and apply configuratio
|
||||
|
||||
Create a folder e2e at the workspace root and a project.json file inside it:
|
||||
|
||||
|
||||
|
||||
|
||||
Add name in `e2e/project.json`:
|
||||
|
||||
@ -285,7 +285,7 @@ npx nx generate @nx/playwright:configuration --project=e2e ---webServerCommand="
|
||||
|
||||
Now I created an e2e folder at the workspace root:
|
||||
|
||||
|
||||
|
||||
_e2e folder_
|
||||
|
||||
Now we can run `npx nx e2e e2e` to run the Playwright e2e tests.
|
||||
|
||||
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 37 KiB After Width: | Height: | Size: 37 KiB |
|
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 10 KiB |
|
Before Width: | Height: | Size: 118 KiB After Width: | Height: | Size: 118 KiB |
|
Before Width: | Height: | Size: 7.2 KiB After Width: | Height: | Size: 7.2 KiB |
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 23 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 38 KiB |
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 23 KiB |
|
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 45 KiB |
|
Before Width: | Height: | Size: 147 KiB After Width: | Height: | Size: 147 KiB |
|
Before Width: | Height: | Size: 100 KiB After Width: | Height: | Size: 100 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
|
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 44 KiB |
|
Before Width: | Height: | Size: 9.9 KiB After Width: | Height: | Size: 9.9 KiB |
|
Before Width: | Height: | Size: 78 KiB After Width: | Height: | Size: 78 KiB |
|
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 36 KiB |
|
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 38 KiB |
|
Before Width: | Height: | Size: 29 KiB After Width: | Height: | Size: 29 KiB |
|
Before Width: | Height: | Size: 5.8 KiB After Width: | Height: | Size: 5.8 KiB |
|
Before Width: | Height: | Size: 9.8 KiB After Width: | Height: | Size: 9.8 KiB |
|
Before Width: | Height: | Size: 78 KiB After Width: | Height: | Size: 78 KiB |
|
Before Width: | Height: | Size: 2.0 MiB After Width: | Height: | Size: 2.0 MiB |
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 23 KiB |
|
Before Width: | Height: | Size: 21 MiB After Width: | Height: | Size: 21 MiB |
|
Before Width: | Height: | Size: 9.9 KiB After Width: | Height: | Size: 9.9 KiB |
|
Before Width: | Height: | Size: 78 KiB After Width: | Height: | Size: 78 KiB |
|
Before Width: | Height: | Size: 70 KiB After Width: | Height: | Size: 70 KiB |
|
Before Width: | Height: | Size: 4.4 KiB After Width: | Height: | Size: 4.4 KiB |
|
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 48 KiB |
|
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 43 KiB |
|
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 48 KiB |
|
Before Width: | Height: | Size: 47 KiB After Width: | Height: | Size: 47 KiB |
|
Before Width: | Height: | Size: 8.1 KiB After Width: | Height: | Size: 8.1 KiB |
|
Before Width: | Height: | Size: 106 KiB After Width: | Height: | Size: 106 KiB |
|
Before Width: | Height: | Size: 6.1 KiB After Width: | Height: | Size: 6.1 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 41 KiB After Width: | Height: | Size: 41 KiB |
|
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
|
Before Width: | Height: | Size: 65 KiB After Width: | Height: | Size: 65 KiB |
|
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 40 KiB |
|
Before Width: | Height: | Size: 9.7 KiB After Width: | Height: | Size: 9.7 KiB |
|
Before Width: | Height: | Size: 126 KiB After Width: | Height: | Size: 126 KiB |
|
Before Width: | Height: | Size: 9.6 KiB After Width: | Height: | Size: 9.6 KiB |
|
Before Width: | Height: | Size: 143 KiB After Width: | Height: | Size: 143 KiB |
|
Before Width: | Height: | Size: 56 KiB After Width: | Height: | Size: 56 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 9.8 KiB After Width: | Height: | Size: 9.8 KiB |
|
Before Width: | Height: | Size: 9.5 KiB After Width: | Height: | Size: 9.5 KiB |
|
Before Width: | Height: | Size: 6.7 KiB After Width: | Height: | Size: 6.7 KiB |
|
Before Width: | Height: | Size: 8.3 KiB After Width: | Height: | Size: 8.3 KiB |
|
Before Width: | Height: | Size: 71 KiB After Width: | Height: | Size: 71 KiB |
|
Before Width: | Height: | Size: 50 KiB After Width: | Height: | Size: 50 KiB |
|
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 40 KiB |
|
Before Width: | Height: | Size: 3.7 KiB After Width: | Height: | Size: 3.7 KiB |
|
Before Width: | Height: | Size: 7.5 KiB After Width: | Height: | Size: 7.5 KiB |
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user