Skip to content

Latest commit

 

History

History
466 lines (299 loc) · 19.6 KB

CHANGELOG.md

File metadata and controls

466 lines (299 loc) · 19.6 KB
Raw

Changelog

Please use the Github Releases page to see the changelog.

1.0.1

Fixes

  • schematic: add a migration to add tsconfig.tools.json (c18baf0)

1.0.0

Fixes

  • schematics: dep-graph visual style for affected lib (8ca8548)
  • schematics: remove strict check for "file" option for dep-graph (6aa6702)
  • schematics: add nxmodule forroot if not existing when generating ngrx for root (e748e81)
  • schematics: don't leak file descriptor in shared.ts/mtime (aa1ff78), closes #403
  • schematics: ignore errors when the tools directory already exists (2a377fe)

0.11.0

Features

0.10.1

Features

Fixes

0.10.0

Features

Fixes

0.9.0

A large workspace contains a lot of apps and libs. Because it is so easy to share code, create new libs and depend on libs, the dependencies between the apps and libs can quickly get out of hand. We need a way to impose constraints on the dependency graph. This release adds this capability.

When creating an app or a lib, you can tag them:

ng g lib apilib --tags=api
ng g lib utilslib --tags=utils
ng g lib impllib --tags=impl
ng g lib untaggedlib

You can also pass multiple tags ng g lib apilib --tags=one,two or modify .angular-cli.json after the fact.

You can then define constraints in tslint.json, like this:

"nx-enforce-module-boundaries": [
  true,
  {
    "allow": [],
    "depConstraints": [
      { "sourceTag": "utils", "onlyDependOnLibsWithTags": ["utils"] },
      { "sourceTag": "api", "onlyDependOnLibsWithTags": ["api", "utils"] },
      { "sourceTag": "impl", "onlyDependOnLibsWithTags": ["api", "utils", "impl"] },
    ]
  }
]

With this configuration in place:

  • utilslib can depend on no libs.
  • apilib can depend on utilslib
  • implib can depend on both utilslib and apilib.
  • untaggedlib can depend on no libs.

This gets really useful once you have multiple libs with the same tag.

You can also use wildcards, like this:

{ "sourceTag": "impl", "onlyDependOnLibsWithTags": ["*"] } // impl can depend on anything
{ "sourceTag": "*", "onlyDependOnLibsWithTags": ["*"] } // anything can depend on anything

The system goes through the constrains until it finds the first one matching the source file it's analyzing.

If we change the configuration to the following:

"nx-enforce-module-boundaries": [
  true,
  {
    "allow": [],
    "depConstraints": [
      { "sourceTag": "utils", "onlyDependOnLibsWithTags": ["utils"] },
      { "sourceTag": "api", "onlyDependOnLibsWithTags": ["api", "utils"] },
      { "sourceTag": "impl", "onlyDependOnLibsWithTags": ["api", "utils", "impl"] },
      { "sourceTag": "*", "onlyDependOnLibsWithTags": ["*"] },
    ]
  }
]

The following will be true.

  • utilslib can depend on no libs.
  • apilib can depend on utilslib
  • implib can depend on both utilslib and apilib.
  • untaggedlib can depend on all libs.

Features

Fixes

0.8.0

Features

Nx no longer uses a patched version of the CLI--we switched to using @angular/cli@1.7.1. We also renamed the nx-migrate command into update to align with the CLI.

Fixes

Cleanup

0.7.4

Features

Fixes

0.7.2

Features

Cleanup

0.7.0

Features

0.7.0-beta.1

Features

0.6.18

Bug Fixes

Cleanup

0.6.13

Bug Fixes

0.6.10

Features

Bug Fixes

0.6.5

Features

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

Bug Fixes

0.6.0

Features

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"

Bug Fixes

0.5.3

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.

Features

Bug Fixes

0.5.2

Bug Fixes

0.5.1

Features

Bug Fixes

0.5.0

Features

0.4.0

Features

Bug Fixes

Refactoring

0.3.0

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.

Features

0.2.2

Bug Fixes

0.2.1

New Features

Bug Fixes

Refactorings

0.2.0

New Features

Changing Default Library Type

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

Generating Router Configuration

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