honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/packages/common/package.json

31 lines
695 B
JSON
Raw Normal View History

repackaging: all the repackaging changes squashed
2016-04-28 20:50:03 -04:00
{
"name": "@angular/common",
chore(package.json): make the packages installable
2016-05-27 19:17:16 -04:00
"version": "0.0.0-PLACEHOLDER",
docs: update descriptions in package.jsons
2016-09-14 19:44:39 -04:00
"description": "Angular - commonly needed directives and services",
repackaging: all the repackaging changes squashed
2016-04-28 20:50:03 -04:00
"author": "angular",
"license": "MIT",
build(common): specify explicit locales dir in package.json (#21016) PR Close #21016
2017-09-29 05:08:12 -04:00
"locales": "locales",
refactor: update to tslib 2.0 and move to direct dependencies (#37198) Tslib version is bound to the TypeScript version used to compile the library. Thus, we shouldn't list `tslib` as a `peerDependencies`. This is because, a user can install libraries which have been compiled with older versions of TypeScript and thus require multiple `tslib` versions to be installed. Reference: TOOL-1374 and TOOL-1375 Closes: #37188 PR Close #37198
2020-05-19 08:35:37 -04:00
"dependencies": {
feat(core): support TypeScript 4.2 (#41158) Updates the repo to TypeScript 4.2 and tslib 2.1.0. PR Close #41158
2021-03-16 15:10:32 -04:00
"tslib": "^2.1.0"
refactor: update to tslib 2.0 and move to direct dependencies (#37198) Tslib version is bound to the TypeScript version used to compile the library. Thus, we shouldn't list `tslib` as a `peerDependencies`. This is because, a user can install libraries which have been compiled with older versions of TypeScript and thus require multiple `tslib` versions to be installed. Reference: TOOL-1374 and TOOL-1375 Closes: #37188 PR Close #37198
2020-05-19 08:35:37 -04:00
},
repackaging: all the repackaging changes squashed
2016-04-28 20:50:03 -04:00
"peerDependencies": {
feat: change tslib from direct dependency to peerDependency (#32167) BREAKING CHANGE: We no longer directly have a direct depedency on `tslib`. Instead it is now listed a `peerDependency`. Users not using the CLI will need to manually install `tslib` via; ``` yarn add tslib ``` or ``` npm install tslib --save ``` PR Close #32167
2019-10-09 10:08:16 -04:00
"@angular/core": "0.0.0-PLACEHOLDER",
refactor: update to tslib 2.0 and move to direct dependencies (#37198) Tslib version is bound to the TypeScript version used to compile the library. Thus, we shouldn't list `tslib` as a `peerDependencies`. This is because, a user can install libraries which have been compiled with older versions of TypeScript and thus require multiple `tslib` versions to be installed. Reference: TOOL-1374 and TOOL-1375 Closes: #37188 PR Close #37198
2020-05-19 08:35:37 -04:00
"rxjs": "^6.5.3"
adds 'repository' metadata to npm modules (#8649)
2016-05-18 02:17:15 -04:00
},
"repository": {
"type": "git",
build(packaging): add repository.directory field to package.jsons (#27544) PR Close #27544
2018-12-07 06:12:59 -05:00
"url": "https://github.com/angular/angular.git",
"directory": "packages/common"
release: add ng update package group metadata to angular (#22482) "ng update" supports having multiple packages as part of a group which should be updated together, meaning that e.g. calling "ng update @angular/core" would be equivalent to updating all packages of the group (that are part of the package.json already). In order to support the grouping feature, the package.json of the version the user is updating to needs to include an "ng-update" key that points to this metadata. The entire specification for the update workflow can be found here: https://github.com/hansl/devkit/blob/2e8b12a4ef53833dc006e8711acf95cf3a6cf24e/docs/specifications/update.md PR Close #22482
2018-02-27 18:04:35 -05:00
},
"ng-update": {
"packageGroup": "NG_UPDATE_PACKAGE_GROUP"
feat: mark angular packages as side-effect free (#22785) This flag is picked up by webpack v4 and used for more agressive optimizations. Our code is already side-effect free, because that's what we needed for build-optimizer to work. PR Close #22785
2018-03-14 21:30:18 -04:00
},
build: support generating global locale files from CLDR data (#33523) In order to support adding locales during compile-time inlining of translations (i.e. after the TS build has completed), we need to be able to attach the locale to the global scope. This commit modifies CLDR extraction to emit additional "global" locale files that appear in the `@angular/common/locales/global` folder. These files are of the form: ``` (function() { const root = typeof globalThis !== 'undefined' && globalThis || typeof global !== 'undefined' && global || typeof window !== 'undefined' && window; root.ng = root.ng || {}; root.ng.common = root.ng.common || {}; root.ng.common.locale = root.ng.common.locale || {}; const u = undefined; function plural(n) { if (n === 1) return 1; return 5; } root.ng.common.locale['xx-yy'] = [...]; })(); ``` The IIFE will ensure that `ng.common.locale` exists and attach the given locale (and its "extras") to it using it "normalized" locale name. * "extras": in the UMD module locale files the "extra" locale data, currently the day period rules, and extended day period data, are stored in separate files under the "common/locales/extra" folder. * "normalized": Angular references locales using a normalized form, which is lower case with `_` replaced by `-`. For example: `en_UK` => `en-uk`. PR Close #33523
2019-10-31 13:29:41 -04:00
"sideEffects": [
"**/global/*.js",
"**/closure-locale.*"
Revert "build: remove wombot proxy registry from package.jsons for release (#37378)" (#37495) This reverts commit 26849ca99dcafc45fb8cb0e97af7aeb85ea11852. PR Close #37495
2020-06-08 21:07:39 -04:00
],
"publishConfig":{
"registry":"https://wombat-dressing-room.appspot.com"
}
repackaging: all the repackaging changes squashed
2016-04-28 20:50:03 -04:00
}