2018-07-16 03:49:56 -04:00
|
|
|
|
#!/usr/bin/env node
|
|
|
|
|
/**
|
|
|
|
|
* @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';
|
2019-03-29 06:13:14 -04:00
|
|
|
|
import {ConsoleLogger, LogLevel} from './src/logging/console_logger';
|
2018-07-16 03:49:56 -04:00
|
|
|
|
|
|
|
|
|
// CLI entry point
|
|
|
|
|
if (require.main === module) {
|
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:
|
|
|
|
|
'A relative path (from the `source` path) to a single entry-point to process (plus its dependencies).',
|
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.',
|
|
|
|
|
type: 'boolean'
|
|
|
|
|
})
|
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'],
|
|
|
|
|
})
|
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;
|
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
|
|
|
|
|
|
|
|
|
(async() => {
|
|
|
|
|
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,
|
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
|
|
|
|
async: true,
|
|
|
|
|
});
|
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
|
|
|
|
}
|