2018-07-16 03:49:56 -04:00
# ! / u s r / b i n / e n v n o d e
/ * *
* @license
* Copyright Google Inc . All Rights Reserved .
*
* Use of this source code is governed by an MIT - style license that can be
* found in the LICENSE file at https : //angular.io/license
* /
2019-03-20 09:47:58 -04:00
import * as yargs from 'yargs' ;
2018-07-16 03:49:56 -04:00
2019-05-15 08:38:19 -04:00
import { resolve , setFileSystem , CachedFileSystem , NodeJSFileSystem } from '../src/ngtsc/file_system' ;
2018-07-16 03:49:56 -04:00
import { mainNgcc } from './src/main' ;
2020-03-05 05:42:28 -05:00
import { ConsoleLogger } from './src/logging/console_logger' ;
import { LogLevel } from './src/logging/logger' ;
2018-07-16 03:49:56 -04:00
// CLI entry point
if ( require . main === module ) {
2020-04-06 04:43:47 -04:00
process . title = 'ngcc' ;
2019-08-29 11:51:02 -04:00
const startTime = Date . now ( ) ;
2018-07-16 03:49:56 -04:00
const args = process . argv . slice ( 2 ) ;
2019-03-20 09:47:58 -04:00
const options =
yargs
. option ( 's' , {
alias : 'source' ,
2019-03-20 09:47:59 -04:00
describe :
'A path (relative to the working directory) of the `node_modules` folder to process.' ,
2019-03-20 09:47:58 -04:00
default : './node_modules'
} )
2019-03-20 09:47:58 -04:00
. option ( 'f' , { alias : 'formats' , hidden : true , array : true } )
. option ( 'p' , {
alias : 'properties' ,
2019-03-20 09:47:58 -04:00
array : true ,
2019-03-20 09:47:58 -04:00
describe :
2019-03-20 09:47:59 -04:00
'An array of names of properties in package.json to compile (e.g. `module` or `es2015`)\n' +
'Each of these properties should hold the path to a bundle-format.\n' +
2019-03-20 09:47:58 -04:00
'If provided, only the specified properties are considered for processing.\n' +
'If not provided, all the supported format properties (e.g. fesm2015, fesm5, es2015, esm2015, esm5, main, module) in the package.json are considered.'
2019-03-20 09:47:58 -04:00
} )
. option ( 't' , {
alias : 'target' ,
2019-03-20 09:47:59 -04:00
describe :
2020-03-16 11:08:47 -04:00
'A relative path (from the `source` path) to a single entry-point to process (plus its dependencies).\n' +
'If this property is provided then `error-on-failed-entry-point` is forced to true' ,
2019-03-20 09:47:58 -04:00
} )
2019-03-20 09:47:58 -04:00
. option ( 'first-only' , {
describe :
2019-03-29 06:13:14 -04:00
'If specified then only the first matching package.json property will be compiled.' ,
2019-03-20 09:47:58 -04:00
type : 'boolean'
} )
2019-10-09 06:36:50 -04:00
. option ( 'create-ivy-entry-points' , {
describe :
'If specified then new `*_ivy_ngcc` entry-points will be added to package.json rather than modifying the ones in-place.\n' +
'For this to work you need to have custom resolution set up (e.g. in webpack) to look for these new entry-points.\n' +
'The Angular CLI does this already, so it is safe to use this option if the project is being built via the CLI.' ,
2019-10-01 08:27:21 -04:00
type : 'boolean' ,
} )
2019-12-03 03:36:38 -05:00
. option ( 'legacy-message-ids' , {
describe : 'Render `$localize` messages with legacy format ids.\n' +
'The default value is `true`. Only set this to `false` if you do not want legacy message ids to\n' +
'be rendered. For example, if you are not using legacy message ids in your translation files\n' +
'AND are not doing compile-time inlining of translations, in which case the extra message ids\n' +
'would add unwanted size to the final source bundle.\n' +
'It is safe to leave this set to true if you are doing compile-time inlining because the extra\n' +
'legacy message ids will all be stripped during translation.' ,
type : 'boolean' ,
default : true ,
} )
2019-10-01 08:27:21 -04:00
. option ( 'async' , {
describe :
'Whether to compile asynchronously. This is enabled by default as it allows compilations to be parallelized.\n' +
'Disabling asynchronous compilation may be useful for debugging.' ,
type : 'boolean' ,
default : true ,
2019-10-09 06:36:50 -04:00
} )
2019-03-29 06:13:14 -04:00
. option ( 'l' , {
alias : 'loglevel' ,
describe : 'The lowest severity logging message that should be output.' ,
choices : [ 'debug' , 'info' , 'warn' , 'error' ] ,
} )
2020-03-10 06:49:17 -04:00
. option ( 'invalidate-entry-point-manifest' , {
describe :
'If this is set then ngcc will not read an entry-point manifest file from disk.\n' +
'Instead it will walk the directory tree as normal looking for entry-points, and then write a new manifest file.' ,
type : 'boolean' ,
default : false ,
} )
2020-03-16 11:08:47 -04:00
. option ( 'error-on-failed-entry-point' , {
describe :
'Set this option in order to terminate immediately with an error code if an entry-point fails to be processed.\n' +
'If `-t`/`--target` is provided then this property is always true and cannot be changed. Otherwise the default is false.\n' +
'When set to false, ngcc will continue to process entry-points after a failure. In which case it will log an error and resume processing other entry-points.' ,
type : 'boolean' ,
default : false ,
} )
2020-03-20 18:09:40 -04:00
. option ( 'tsconfig' , {
describe :
'A path to a tsconfig.json file that will be used to configure the Angular compiler and module resolution used by ngcc.\n' +
'If not provided, ngcc will attempt to read a `tsconfig.json` file from the folder above that given by the `-s` option.\n' +
'Set to false (via `--no-tsconfig`) if you do not want ngcc to use any `tsconfig.json` file.' ,
type : 'string' ,
} )
fix(ngcc): show helpful error when providing an invalid option (#36010)
Currently, when running the ngcc binary directly and provide an invalid option ngcc will not error out and the user might have a hard time telling why ngcc is behaving not as expected.
With this change we now output an actionable error:
```
yarn ngcc --unknown-option
Options:
--version Show version number [boolean]
-s, --source A path (relative to the working directory)
of the `node_modules` folder to process.
[default: "./node_modules"]
-p, --properties An array of names of properties in
package.json to compile (e.g. `module` or
`es2015`)
Each of these properties should hold the
path to a bundle-format.
If provided, only the specified properties
are considered for processing.
If not provided, all the supported format
properties (e.g. fesm2015, fesm5, es2015,
esm2015, esm5, main, module) in the
package.json are considered. [array]
-t, --target A relative path (from the `source` path) to
a single entry-point to process (plus its
dependencies).
--first-only If specified then only the first matching
package.json property will be compiled.
[boolean]
--create-ivy-entry-points If specified then new `*_ivy_ngcc`
entry-points will be added to package.json
rather than modifying the ones in-place.
For this to work you need to have custom
resolution set up (e.g. in webpack) to look
for these new entry-points.
The Angular CLI does this already, so it is
safe to use this option if the project is
being built via the CLI. [boolean]
--legacy-message-ids Render `$localize` messages with legacy
format ids.
The default value is `true`. Only set this
to `false` if you do not want legacy
message ids to
be rendered. For example, if you are not
using legacy message ids in your
translation files
AND are not doing compile-time inlining of
translations, in which case the extra
message ids
would add unwanted size to the final source
bundle.
It is safe to leave this set to true if you
are doing compile-time inlining because the
extra
legacy message ids will all be stripped
during translation.
[boolean] [default: true]
--async Whether to compile asynchronously. This is
enabled by default as it allows
compilations to be parallelized.
Disabling asynchronous compilation may be
useful for debugging.
[boolean] [default: true]
-l, --loglevel The lowest severity logging message that
should be output.
[choices: "debug", "info", "warn", "error"]
--invalidate-entry-point-manifest If this is set then ngcc will not read an
entry-point manifest file from disk.
Instead it will walking the directory tree
as normal looking for entry-points, and
then write a new manifest file.
[boolean] [default: false]
--help Show help [boolean]
Unknown arguments: unknown-option, unknownOption
```
PR Close #36010
2020-03-11 07:42:56 -04:00
. strict ( )
2019-03-20 09:47:58 -04:00
. help ( )
. parse ( args ) ;
2019-03-20 09:47:58 -04:00
if ( options [ 'f' ] && options [ 'f' ] . length ) {
console . error (
'The formats option (-f/--formats) has been removed. Consider the properties option (-p/--properties) instead.' ) ;
process . exit ( 1 ) ;
}
2019-06-06 15:22:32 -04:00
2019-05-15 08:38:19 -04:00
setFileSystem ( new CachedFileSystem ( new NodeJSFileSystem ( ) ) ) ;
2019-06-06 15:22:32 -04:00
const baseSourcePath = resolve ( options [ 's' ] || './node_modules' ) ;
2019-03-20 09:47:59 -04:00
const propertiesToConsider : string [ ] = options [ 'p' ] ;
const targetEntryPointPath = options [ 't' ] ? options [ 't' ] : undefined ;
2019-03-20 09:47:58 -04:00
const compileAllFormats = ! options [ 'first-only' ] ;
2019-10-09 06:36:50 -04:00
const createNewEntryPointFormats = options [ 'create-ivy-entry-points' ] ;
2019-04-03 11:37:36 -04:00
const logLevel = options [ 'l' ] as keyof typeof LogLevel | undefined ;
2019-12-03 03:36:38 -05:00
const enableI18nLegacyMessageIdFormat = options [ 'legacy-message-ids' ] ;
2020-03-10 06:49:17 -04:00
const invalidateEntryPointManifest = options [ 'invalidate-entry-point-manifest' ] ;
2020-03-16 11:08:47 -04:00
const errorOnFailedEntryPoint = options [ 'error-on-failed-entry-point' ] ;
2020-03-20 18:09:40 -04:00
// yargs is not so great at mixed string+boolean types, so we have to test tsconfig against a
// string "false" to capture the `tsconfig=false` option.
// And we have to convert the option to a string to handle `no-tsconfig`, which will be `false`.
const tsConfigPath = ` ${ options [ 'tsconfig' ] } ` === 'false' ? null : options [ 'tsconfig' ] ;
refactor(ngcc): add support for asynchronous execution (#32427)
Previously, `ngcc`'s programmatic API would run and complete
synchronously. This was necessary for specific usecases (such as how the
`@angular/cli` invokes `ngcc` as part of the TypeScript module
resolution process), but not for others (e.g. running `ivy-ngcc` as a
`postinstall` script).
This commit adds a new option (`async`) that enables turning on
asynchronous execution. I.e. it signals that the caller is OK with the
function call to complete asynchronously, which allows `ngcc` to
potentially run in a more efficient mode.
Currently, there is no difference in the way tasks are executed in sync
vs async mode, but this change sets the ground for adding new execution
options (that require asynchronous operation), such as processing tasks
in parallel on multiple processes.
NOTE:
When using the programmatic API, the default value for `async` is
`false`, thus retaining backwards compatibility.
When running `ngcc` from the command line (i.e. via the `ivy-ngcc`
script), it runs in async mode (to be able to take advantage of future
optimizations), but that is transparent to the caller.
PR Close #32427
2019-08-19 15:58:22 -04:00
2020-04-06 03:30:08 -04:00
( async ( ) = > {
refactor(ngcc): add support for asynchronous execution (#32427)
Previously, `ngcc`'s programmatic API would run and complete
synchronously. This was necessary for specific usecases (such as how the
`@angular/cli` invokes `ngcc` as part of the TypeScript module
resolution process), but not for others (e.g. running `ivy-ngcc` as a
`postinstall` script).
This commit adds a new option (`async`) that enables turning on
asynchronous execution. I.e. it signals that the caller is OK with the
function call to complete asynchronously, which allows `ngcc` to
potentially run in a more efficient mode.
Currently, there is no difference in the way tasks are executed in sync
vs async mode, but this change sets the ground for adding new execution
options (that require asynchronous operation), such as processing tasks
in parallel on multiple processes.
NOTE:
When using the programmatic API, the default value for `async` is
`false`, thus retaining backwards compatibility.
When running `ngcc` from the command line (i.e. via the `ivy-ngcc`
script), it runs in async mode (to be able to take advantage of future
optimizations), but that is transparent to the caller.
PR Close #32427
2019-08-19 15:58:22 -04:00
try {
2019-08-29 11:51:02 -04:00
const logger = logLevel && new ConsoleLogger ( LogLevel [ logLevel ] ) ;
refactor(ngcc): add support for asynchronous execution (#32427)
Previously, `ngcc`'s programmatic API would run and complete
synchronously. This was necessary for specific usecases (such as how the
`@angular/cli` invokes `ngcc` as part of the TypeScript module
resolution process), but not for others (e.g. running `ivy-ngcc` as a
`postinstall` script).
This commit adds a new option (`async`) that enables turning on
asynchronous execution. I.e. it signals that the caller is OK with the
function call to complete asynchronously, which allows `ngcc` to
potentially run in a more efficient mode.
Currently, there is no difference in the way tasks are executed in sync
vs async mode, but this change sets the ground for adding new execution
options (that require asynchronous operation), such as processing tasks
in parallel on multiple processes.
NOTE:
When using the programmatic API, the default value for `async` is
`false`, thus retaining backwards compatibility.
When running `ngcc` from the command line (i.e. via the `ivy-ngcc`
script), it runs in async mode (to be able to take advantage of future
optimizations), but that is transparent to the caller.
PR Close #32427
2019-08-19 15:58:22 -04:00
await mainNgcc ( {
basePath : baseSourcePath ,
propertiesToConsider ,
targetEntryPointPath ,
compileAllFormats ,
2019-10-09 06:36:50 -04:00
createNewEntryPointFormats ,
2019-08-29 11:51:02 -04:00
logger ,
2019-12-03 03:36:38 -05:00
enableI18nLegacyMessageIdFormat ,
2020-04-06 03:30:08 -04:00
async : options [ 'async' ] ,
invalidateEntryPointManifest ,
errorOnFailedEntryPoint ,
tsConfigPath
refactor(ngcc): add support for asynchronous execution (#32427)
Previously, `ngcc`'s programmatic API would run and complete
synchronously. This was necessary for specific usecases (such as how the
`@angular/cli` invokes `ngcc` as part of the TypeScript module
resolution process), but not for others (e.g. running `ivy-ngcc` as a
`postinstall` script).
This commit adds a new option (`async`) that enables turning on
asynchronous execution. I.e. it signals that the caller is OK with the
function call to complete asynchronously, which allows `ngcc` to
potentially run in a more efficient mode.
Currently, there is no difference in the way tasks are executed in sync
vs async mode, but this change sets the ground for adding new execution
options (that require asynchronous operation), such as processing tasks
in parallel on multiple processes.
NOTE:
When using the programmatic API, the default value for `async` is
`false`, thus retaining backwards compatibility.
When running `ngcc` from the command line (i.e. via the `ivy-ngcc`
script), it runs in async mode (to be able to take advantage of future
optimizations), but that is transparent to the caller.
PR Close #32427
2019-08-19 15:58:22 -04:00
} ) ;
2019-08-29 11:51:02 -04:00
if ( logger ) {
const duration = Math . round ( ( Date . now ( ) - startTime ) / 1000 ) ;
logger . debug ( ` Run ngcc in ${ duration } s. ` ) ;
}
refactor(ngcc): add support for asynchronous execution (#32427)
Previously, `ngcc`'s programmatic API would run and complete
synchronously. This was necessary for specific usecases (such as how the
`@angular/cli` invokes `ngcc` as part of the TypeScript module
resolution process), but not for others (e.g. running `ivy-ngcc` as a
`postinstall` script).
This commit adds a new option (`async`) that enables turning on
asynchronous execution. I.e. it signals that the caller is OK with the
function call to complete asynchronously, which allows `ngcc` to
potentially run in a more efficient mode.
Currently, there is no difference in the way tasks are executed in sync
vs async mode, but this change sets the ground for adding new execution
options (that require asynchronous operation), such as processing tasks
in parallel on multiple processes.
NOTE:
When using the programmatic API, the default value for `async` is
`false`, thus retaining backwards compatibility.
When running `ngcc` from the command line (i.e. via the `ivy-ngcc`
script), it runs in async mode (to be able to take advantage of future
optimizations), but that is transparent to the caller.
PR Close #32427
2019-08-19 15:58:22 -04:00
process . exitCode = 0 ;
} catch ( e ) {
console . error ( e . stack || e . message ) ;
process . exitCode = 1 ;
}
} ) ( ) ;
2018-07-16 03:49:56 -04:00
}