The nrwl/nx and nrwl/schematics packages are released together. You must use the same version of the two packages.
- Fixed affected: commands. Continue traversing within irrelevant PropertyAssignment nodes
- Make affected and format windows-friendly
- Avoid relative paths to node modules
- Handle the case when libraries are placed in the directory with the same name as an app
- Handle circular deps between apps and libs
- Handle projects that have similar names
- Update workspace to set $schema and app name
- Update workspace to copy the cli file
- Disallow importing apps
This release adds the following commands:
npm run format:write -- SHA1 SHA2
npm run format:check -- SHA1 SHA2
The format:check command checks that the files touched between the given SHAs are formatted properly, and format:write formats them.
Instead of passing the two SHAs, you can also pass the list of files, like this:
npm run format:write -- --files="libs/mylib/index.ts,libs/mylib2/index.ts"
npm run format:check -- --files="libs/mylib/index.ts,libs/mylib2/index.ts"
You can add --libs-and-apps flag to always run the formatter on apps and libs instead of individual files.
npm run format:write -- SHA1 SHA2 --libs-and-apps
npm run format:check -- SHA1 SHA2 --libs-and-apps
Finally, you can the command on the whole repo, like this:
npm run format:write
npm run format:check
This release adds the following commands:
npm run apps:affected -- SHA1 SHA2
npm run build:affected -- SHA1 SHA2
npm run e2e:affected -- SHA1 SHA2
The apps:affected prints the apps that are affected by the commits between the given SHAs. The build:affected builds them, and e2e:affected runs their e2e tests.
To be able to do that, Nx analyzes your monorepo to figure out the dependency graph or your libs and apps. Next, it looks at the files touched by the commits to figure out what apps and libs they belong to. Finally, it uses all this information to generate the list of apps that can be affected by the commits.
Instead of passing the two SHAs, you can also pass the list of files, like this:
npm run apps:affected -- --files="libs/mylib/index.ts,libs/mylib2/index.ts"
npm run build:affected ----files="libs/mylib/index.ts,libs/mylib2/index.ts"
npm run e2e:affected ----files="libs/mylib/index.ts,libs/mylib2/index.ts"
ng new myproj --collection=@nrwl/schematics creates a new workspace.
For this to work @nrwl/schematics and @angular/cli have to be installed globally, and they have to be compatible. This is error prone, and it often results in hard to debug errors. And it is impossible for Nx to solve this problem because we do not control your globally installed npm modules.
That is why we provided a way to create a new workspace using a sandbox that does not depend on any global modules, like this:
curl -fsSL https://raw.githubusercontent.com/nrwl/nx/master/packages/install/install.sh | bash -s myprojectname
This works, but with one caveat: you have to have curl and bash installed, which might be a problem for a lot of windows folks. That is why starting with 0.5.3, @nrwl/schematics ships with a binary that works on all platforms and creates an Nx workspace without relying on globally installed npm modules.
This is what you can do now:
yarn global add @nrwl/schematics # do it once
create-nx-workspace myproj
Some folks also reported having problems running Nx behind a firewall, in a corporate environment. We fixed them as well.
- Remove default prop for viewEncapsulation option flag
- Fix NPM link in README
- Change rxjs version to use hat
- Add support for generating nested apps and libs
- Update NgRx schematic to allow the customization of the state folder
- Only begin converting to workspace once files have been checked
- "ng build" should only recompile the selected app
We want to be able to add new features to Nx without breaking existing workspaces. Say, you created an Nx Workspace using Nx 0.2.0. Then, half a year later, you decided to upgrade the version of Nx to 0.5.0. Imagine the 0.5.0 release requires you to have more information in your .angular-cli.json. Until now, you would have to manually go through the changelog and modify your .angular-cli.json. This release adds the nx-migrate command that does it for you. Run npm run nx-migrate after upgrading @nrwl/schematics, and it will upgrade your workspace to be 0.5.0 compatible.
- add
allowoption to whitelist deep imports - Added the nx-migrate command
- Upgrade Prettier to 1.8.2
- Update readme to point to example apps using Nx
- Adds a schema file to allow custom properties that the default CLI distribution does not support
- Fix issue with generating a wrong full path on windows
- Export jasmine-marbles getTestScheduler and time functions
- Use fetch instead of optimisticUpdate in the generated effect classes
We changed the default library type from "simple" to "Angular". So where previously you would run:
ng generate lib mylib // simple TS library
ng generate lib mylib --ngmodule // an angular library
Now, you run:
ng generate lib mylib // an angular library
ng generate lib mylib --nomodule // simple ts library
You can pass --routing when generating an app.
ng generate app myapp --routing // generate an angular app with router config
The generated app will have RouterModule.forRoot configured.
You can also pass it when generating a library, like this:
ng generate lib mylib --routing
This will set up the router module and will create an array of routes, which can be plugged into the parent module. This configuration works well for modules that aren't loaded lazily.
You can add the --lazy to generate a library that is loaded lazily.
ng generate lib mylib --routing --lazy
This will also register the generated library in tslint.json, so the linters will make sure the library is not loaded lazily.
Finally, you can pass --parentModule and the schematic will wire up the generated library in the parent router configuration.
ng generate lib mylib --routing --parentModule=apps/myapp/src/myapp.module.ts
ng generate lib mylib --routing --lazy --parentModule=apps/myapp/src/myapp.module.ts