A full featured tool set for Persian Applications Created by Angular (v > 2) containing Pipes, Services, Directives and javascript Similar Date object for working with Jalali Date.
ChatGPT is bullshit
Recently, there has been considerable interest in large language models: machine learning systems which produce human-like text and dialogue. Applications of these systems have been plagued by persistent inaccuracies in their output; these are often called “AI hallucinations”. We argue that these falsehoods, and the overall activity of large language models, is better understood as bullshit in the sense explored by Frankfurt (On Bullshit, Princeton, 2005): the models are in an important way indifferent to the truth of their outputs. We distinguish two ways in which the models can be said to be bullshitters, and argue that they clearly meet at least one of these definitions. We further argue that describing AI misrepresentations as bullshit is both a more useful and more accurate way of predicting and discussing the behaviour of these systems.
React Native, a new way to write native mobile apps. The technology takes everything that's great about React.js and applies it to native apps. You write JavaScript components using a set of builtin primitives that are backed by actual native iOS or Android c
Twitter: "Want to throw together a quick web application in C#? This is what that will look like in the future.
روش ذکر فایل‌های ایستا در کامپوننت‌های جاوا اسکریپتی برنامه‌های React
React، برای مدیریت پروژه‌ی خود، از Webpack استفاده می‌کند و در این حالت، کار با فایل‌های ایستا مانند تصاویر و قلم‌های وب، شبیه به کار با فایل‌های CSS خواهد بود؛ یعنی این نوع فایل‌ها را باید در فایل‌های جاوا اسکریپتی برنامه، import کرد. به این ترتیب Webpack کار یکی سازی این فایل‌ها را با bundle نهایی تولید شده، انجام می‌دهد.
یک مثال: فرض کنید فایل button.css به صورت زیر تعریف شده‌است:
برای استفاده‌ی از این فایل css در یک کامپوننت، ابتدا آن‌را import کرده و سپس از classNameهای تعریف شده‌ی در آن استفاده می‌کنیم:
البته برخلاف حالت کار با CSS imports، با import یک فایل ایستا، یک رشته در اختیار ما قرار می‌گیرد که از آن می‌توان در کدهای خود استفاده کرد. برای کاهش تعداد رفت و برگشت‌های به سرور، اگر فایل‌های تصویری با فرمت‌های bmp, gif, jpg, jpeg و png، کمتر از 10,000 بایت باشند، از data URI آن‌ها بجای مسیر نهایی استفاده خواهد شد. این مورد شامل فایل‌های svg نمی‌شود.
یک مثال:
در اینجا ابتدا یک فایل تصویری، import شده‌است. سپس می‌توان از رشته‌ی متناظر با آن، به عنوان src المان تصویر استفاده کرد.
این مورد برای تصاویر ذکر شده‌ی در فایل‌های CSS نیز صادق است:
Webpack در فایل‌های CSS به دنبال مسیرهای فایل‌های ثابت شروع شده‌ی با /. می‌گردد و مسیرهای این نوع فایل‌ها را با مسیر نهایی ارائه‌ی برنامه، به صورت خودکار جایگزین و اصلاح می‌کند. همچنین نیازی هم به نگرانی در مورد کش شدن این فایل‌های ثابت وجود ندارد؛ چون webpack از نام‌های خاصی به همراه hash این نوع فایل‌ها، برای جایگزینی نهایی استفاده خواهد کرد و اگر محتوای فایل‌های ثابت تغییر کنند، این هش نیز تغییر کره و مرورگر نگارش جدید آن‌ها را دریافت می‌کند. مزیت دیگر کار با webpack، ارائه‌ی خطاهای زمان کامپایل برنامه است. برای مثال اگر فایل‌های ثابت مورد استفاده‌ی در برنامه به درستی مسیر دهی نشده باشند، یک خطای زمان کامپایل صادر می‌شود.
یک مثال: فرض کنید در برنامه‌ی ASP.NET Core خود که با React یکی شده‌است، فایل project_folder/ClientApp/src/images/progress_bar.gif را قرار داده‌اید. روش import آن با توجه به مسیرهای نسبی برنامه به صورت زیر است:
و روش فراخوانی آن در کدهای یک کامپوننت به نحو زیر خواهد بود:
روش ذکر فایل‌های ایستا در کامپوننت‌های تایپ اسکریپتی برنامه‌های React
اگر از تایپ‌اسکریپت استفاده می‌کنید، چنین importهایی سبب بروز خطای «'Cannot find module './logo.png» می‌شوند. برای رفع این مشکل، فایلی را به نام assets.d.ts به پروژه‌ی خود اضافه کرده و آن‌را به صورت زیر تکمیل کنید:
به این ترتیب پسوند‌های فایل‌های مختلف ایستا، به عنوان فرمت‌های مجاز ماژول‌ها، قابل استفاده می‌شوند.
نحوه‌ی پردازش پوشه‌ی ویژه‌ی public در برنامه‌های React
اگر فایلی در پوشه‌ی ویژه‌ی public برنامه‌های react قرار گیرد، توسط webpack پردازش نخواهد شد. در این حالت این نوع فایل‌ها بدون هیچ نوع تغییری به پوشه‌ی build نهایی کپی می‌شوند. بنابراین برای کار با فایل‌های ایستای قرار گرفته‌ی در پوشه‌ی public باید از متغیر خاصی به نام PUBLIC_URL استفاده کرد. برای مثال درون فایل index.html، چنین تعریفی را می‌توان مشاهده کرد:
اگر نیاز به استفاده‌ی از فایلی درون پوشه‌ی src و یا node_modules دارید، باید آن‌ها را به این پوشه کپی کنید تا جزئی از پروسه‌ی build شوند. متغیر PUBLIC_URL در زمان اجرای دستور npm run build، با مسیر صحیحی جایگزین خواهد شد.
برای دسترسی به این مسیر در کامپوننت‌های برنامه نیز می‌توان از متغیر محیطی process.env.PUBLIC_URL استفاده کرد:
البته روش توصیه شده، همان ذکر importهای فایل‌های ایستا است و بهتر است از این متغیر محیطی زیاد استفاده نکنید؛ چون پردازش ثانویه‌ای بر روی آن‌ها صورت نمی‌گیرد و یا minified نمی‌شوند. نبود آن‌ها سبب بروز خطای زمان کامپایل نخواهد شد و همچنین هیچ hash ای به نام نهایی آن‌ها به صورت خودکار اضافه نمی‌گردد که ممکن است سبب بروز مشکلات کش شدن طولانی مدت این فایل‌های ایستا شود.
بنابراین اکنون این سؤال مطرح می‌شود که چه زمانی بهتر است از پوشه‌ی public استفاده شود؟
- اگر می‌خواهید نام فایل نهایی ایستای مدنظر مانند manifest.json، بدون تغییر باقی بماند.
- هزاران فایل ایستا را دارید و می‌خواهید این مسیرها را به صورت پویا در برنامه فراخوانی کنید (و قرار نیست جزئی از bundle نهایی شوند).
- می‌خواهید فایل‌های js خاصی را خارج از سیستم bundle اصلی قرار دهید؛ چون به هر دلیلی این نوع فایل‌ها با سیستم webpack سازگاری ندارند و نباید توسط آن پردازش شوند. در این حالت باید این نوع فایل‌ها را با تگ script به فایل index.html به صورت دستی معرفی کنید.
React، برای مدیریت پروژه‌ی خود، از Webpack استفاده می‌کند و در این حالت، کار با فایل‌های ایستا مانند تصاویر و قلم‌های وب، شبیه به کار با فایل‌های CSS خواهد بود؛ یعنی این نوع فایل‌ها را باید در فایل‌های جاوا اسکریپتی برنامه، import کرد. به این ترتیب Webpack کار یکی سازی این فایل‌ها را با bundle نهایی تولید شده، انجام می‌دهد.
یک مثال: فرض کنید فایل button.css به صورت زیر تعریف شده‌است:
.Button {
padding: 20px;
} برای استفاده‌ی از این فایل css در یک کامپوننت، ابتدا آن‌را import کرده و سپس از classNameهای تعریف شده‌ی در آن استفاده می‌کنیم:
import React, { Component } from 'react';
import './Button.css';
class Button extends Component {
render() {
return <div className="Button" />;
}
} در حالت توسعه، با هر تغییری در این فایل css، بارگذاری مجدد برنامه به صورت خودکار صورت گرفته و نتیجه‌ی نهایی رندر خواهد شد. در حالت نهایی ارائه‌ی برنامه، تمام فایل‌های css، با هم یکی شده و نگارش minified آن‌ها، به bundle نهایی برنامه اضافه می‌شوند. توصیه شده‌است یک فایل css را در چندین کامپوننت برنامه import نکنید. بهتر است یک کامپوننت دکمه را ایجاد کنید که فایل css مشخصی را import می‌کند و سپس از آن کامپوننت در قسمت‌های مختلف برنامه استفاده کنید.
البته برخلاف حالت کار با CSS imports، با import یک فایل ایستا، یک رشته در اختیار ما قرار می‌گیرد که از آن می‌توان در کدهای خود استفاده کرد. برای کاهش تعداد رفت و برگشت‌های به سرور، اگر فایل‌های تصویری با فرمت‌های bmp, gif, jpg, jpeg و png، کمتر از 10,000 بایت باشند، از data URI آن‌ها بجای مسیر نهایی استفاده خواهد شد. این مورد شامل فایل‌های svg نمی‌شود.
یک مثال:
import React from 'react';
import logo from './logo.svg';
console.log(logo);
function Header() {
return <img src={logo} alt="Logo" />;
}
export default Header; این مورد برای تصاویر ذکر شده‌ی در فایل‌های CSS نیز صادق است:
.Logo {
background-image: url(./logo.png);
} یک مثال: فرض کنید در برنامه‌ی ASP.NET Core خود که با React یکی شده‌است، فایل project_folder/ClientApp/src/images/progress_bar.gif را قرار داده‌اید. روش import آن با توجه به مسیرهای نسبی برنامه به صورت زیر است:
import progressBar from '../images/progress_bar.gif';
<img alt="loading..." src={progressBar} /> روش ذکر فایل‌های ایستا در کامپوننت‌های تایپ اسکریپتی برنامه‌های React
اگر از تایپ‌اسکریپت استفاده می‌کنید، چنین importهایی سبب بروز خطای «'Cannot find module './logo.png» می‌شوند. برای رفع این مشکل، فایلی را به نام assets.d.ts به پروژه‌ی خود اضافه کرده و آن‌را به صورت زیر تکمیل کنید:
declare module "*.gif"; declare module "*.jpg"; declare module "*.jpeg"; declare module "*.png"; declare module "*.svg";
نحوه‌ی پردازش پوشه‌ی ویژه‌ی public در برنامه‌های React
اگر فایلی در پوشه‌ی ویژه‌ی public برنامه‌های react قرار گیرد، توسط webpack پردازش نخواهد شد. در این حالت این نوع فایل‌ها بدون هیچ نوع تغییری به پوشه‌ی build نهایی کپی می‌شوند. بنابراین برای کار با فایل‌های ایستای قرار گرفته‌ی در پوشه‌ی public باید از متغیر خاصی به نام PUBLIC_URL استفاده کرد. برای مثال درون فایل index.html، چنین تعریفی را می‌توان مشاهده کرد:
<link rel="shortcut icon" href="%PUBLIC_URL%/favicon.ico">
برای دسترسی به این مسیر در کامپوننت‌های برنامه نیز می‌توان از متغیر محیطی process.env.PUBLIC_URL استفاده کرد:
render() {
return <img src={process.env.PUBLIC_URL + '/img/logo.png'} />;
} بنابراین اکنون این سؤال مطرح می‌شود که چه زمانی بهتر است از پوشه‌ی public استفاده شود؟
- اگر می‌خواهید نام فایل نهایی ایستای مدنظر مانند manifest.json، بدون تغییر باقی بماند.
- هزاران فایل ایستا را دارید و می‌خواهید این مسیرها را به صورت پویا در برنامه فراخوانی کنید (و قرار نیست جزئی از bundle نهایی شوند).
- می‌خواهید فایل‌های js خاصی را خارج از سیستم bundle اصلی قرار دهید؛ چون به هر دلیلی این نوع فایل‌ها با سیستم webpack سازگاری ندارند و نباید توسط آن پردازش شوند. در این حالت باید این نوع فایل‌ها را با تگ script به فایل index.html به صورت دستی معرفی کنید.
The Angular 2 Notes for Professionals book is compiled from Stack Overflow Documentation
John Bristowe from Telerik does a detailed walkthrough of Kendo UI with Angular JS
The long-term-support (LTS) version 3.1 of Microsoft .NET Core Framework is slated to go out of support on December 13th, 2022. Microsoft recommends upgrading .NET Core 3.1 applications to .NET 6.0 to stay supported for the future, while the developers have mixed feelings about the .NET support policy.
یکی از مواردی که با Angular CLI 6.0 به شدت ساده شده‌است، ایجاد پروژه‌های «کتابخانه» Angular است. برای مثال شاید در حین استفاده‌ی از بعضی از کتابخانه‌ی ثالث تهیه شده‌ی برای Angular با خطای ذیل مواجه شده باشید:
این خطا زمانی رخ می‌دهد که تهیه کننده‌ی کتابخانه، فرمت بسته‌های Angular را رعایت نکرده باشد و ... رعایت کردن آن نیز کار بسیار مشکلی است. نگارش 6 در پشت صحنه، پروژه‌ی موفق ng-packagr را به مجموعه‌ی CLI اضافه کرده‌است و از این پس توسط خود CLI می‌توان کتابخانههای استاندارد Angular را تولید کرد. این مورد، مزیت استاندارد سازی کتابخانههای npm حاصل را نیز به همراه دارد. مشکلی که گاهی از اوقات به علت عدم رعایت این ساختار با بسته‌های فعلی npm مخصوص Angular وجود دارند؛ مانند خطایی که عنوان شد. برای مثال بدون استفاده‌ی از این ابزار، نیاز است مستندات چند صفحه‌ای ساخت کتابخانههای Angular را سطر به سطر پیاده سازی کنید که توسط CLI 6.0 به صورت خودکار ایجاد و مدیریت می‌شود.
مراحل ایجاد یک پروژه‌ی «کتابخانه» توسط Angular CLI 6.0
مرحله‌ی اول ایجاد یک پروژه‌ی کتابخانه، مانند قبل، توسط دستور ng new و ایجاد یک پروژه‌ی دلخواه جدید است:
به همراه Angular CLI 6.0، فرمت تنظیمات آن نیز تغییر کرده‌است و مفهوم workspace به آن اضافه شده‌است که در آن می‌توان چندین پروژه را تعریف کرد.
پس از ایجاد پروژه‌ی my-lib-test توسط دستور فوق و وارد شدن به پوشه‌ی اصلی آن توسط خط فرمان، می‌توان با اجرای دستور زیر، پروژه‌های دیگری را به پروژه‌ی جاری افزود:
اما اگر در اینجا بجای ذکر application، از نام library استفاده کنیم، یک کتابخانه را بجای یک برنامه، به workspace جاری اضافه می‌کند:
پس از اجرای این دستور اگر به فایل angular.json دقت کنیم، این پروژه در ذیل projects اضافه شده‌است:
همچنین یک پوشه‌ی جدید به نام projects نیز ایجاد شده و پروژه‌ی my-lib داخل آن قرار گرفته‌است.
فایل جدید public_api.ts
پس از ایجاد کتابخانه‌ی جدید «my-lib»، فایل جدیدی به نام projects\my-lib\src\public_api.ts نیز به آن اضافه شده‌است:
با این محتوا:
هر خروجی که در اینجا ذکر شود توسط استفاده کنندگان از این کتابخانه قابل دسترسی خواهد بود. برای مثال دستور «ng generate library my-lib» مطابق تصویر فوق، یک سرویس جدید را به نام my-lib.service، یک کامپوننت جدید را به نام my-lib.component و یک ماژول جدید را به نام my-lib.module به صورت پیش‌فرض ایجاد کرده و درون پوشه‌ی lib قرار داده‌است. اکنون آن‌ها را توسط فایل public_api.ts، به نحوی که مشاهده می‌کنید در معرض دید استفاده کنندگان قرار می‌دهد.
برای مثال اگر فایل جدید projects\my-lib\src\lib\my-lib.models.ts را به این کتابخانه اضافه کنیم که شامل تعدادی مدل و اینترفیس قابل دسترسی توسط استفاده کنندگان باشد، باید یک سطر زیر را به انتهای فایل public_api.ts اضافه کنیم:
این پروژه‌ی کتابخانه حتی به همراه فایل‌های package.json, tsconfig.json, tslint.json مخصوص به خود نیز می‌باشد تا بتوان آن‌ها را صرفا جهت این پروژه سفارشی سازی کرد.
ساختار my-lib.service پیش‌فرض یک پروژه‌ی کتابخانه
اگر به فایل projects\my-lib\src\lib\my-lib.service.ts دقت کنیم:
تمام قسمت‌های آن مانند قبل است، منهای 'providedIn: 'root آن. این مورد تنظیم جدیدی است که در پروژه‌های Angular 6 قابل استفاده‌است. هدف از آن، ارائه‌ی یک سرویس، بدون نیاز به ثبت صریح آن در قسمت providers یک NgModule است.
شاید بپرسید چرا؟ هدف اصلی از آن، بهبود فرآیند tree-shaking یا حذف کدهای مرده و استفاده نشده‌است. ممکن است سرویسی را تعریف کنید، اما در برنامه استفاده نشود. این حالت خصوصا در پروژه‌های کتابخانههای ثالث ممکن است زیاد رخ دهد. به همین جهت با ارائه‌ی این قابلیت، امکان حذف ساده‌تر سرویس‌هایی که در برنامه استفاده نشده‌اند از خروجی نهایی کامپایل شده، وجود خواهد داشت.
چگونه به پروژه‌ی کتابخانه‌ی جدید، یک کامپوننت جدید را اضافه کنیم؟
تمام دستورات Angular CLI، در اینجا نیز کار می‌کنند. تنها تفاوت آن‌ها، ذکر صریح نام پروژه‌ی مورد استفاده است:
دستور فوق کامپوننت جدید show-data را به پروژه‌ی my-lib اضافه خواهد کرد؛ به همراه به روز رسانی خودکار فایل projects/my-lib/src/lib/my-lib.module.ts این پروژه، جهت ثبت کامپوننت اضافه شده.
البته در اینجا باید فایل my-lib.module.ts را اندکی ویرایش کرد و ShowDataComponent را به قسمت exports نیز افزود:
به صورت پیش‌فرض، کامپوننت جدید را در قسمت declarations معرفی می‌کند. یک چنین کامپوننتی فقط داخل همان lib قابل استفاده‌است. اگر قرار است خارج از این lib نیز به آن دسترسی داشته باشیم، باید آن‌را در قسمت exports نیز قید کنیم.
همچنین قسمت imports آن نیز به صورت پیش‌فرض خالی است. اگر نیاز است با ngIf کار کنید، باید CommonModule را در اینجا قید کنید و اگر نیاز است تبادلات HTTP وجود داشته باشد، ذکر HttpClientModule نیز ضروری است.
مرحله‌ی ساخت پروژه
پیش از استفاده‌ی از این پروژه‌ی کتابخانه، باید آن‌را build کرد:
در اینجا نیز دستور ng build مانند قبل است، با این تفاوت که نام پروژه‌ی کتابخانه نیز در اینجا ذکر شده‌است.
پس از اجرای این دستور، خروجی ذیل مشاهده می‌شود:
همانطور که ملاحظه می‌کنید، پس از طی مراحل خاص تولید یک کتابخانه، خروجی نهایی آن‌را در پوشه‌ی dist\my-lib قرار داده‌است.
استفاده‌ی از کتابخانه‌ی تولید شده
پس از پایان موفقیت آمیز مرحله‌ی Build، اکنون نوبت به استفاده‌ی از این کتابخانه است. استفاده‌ی از آن نیز همانند تمام کتابخانه‌ها و وابستگی‌های ثالثی است که تا پیش از این از آن‌ها استفاده کرده‌ایم. برای مثال ماژول آن‌را در قسمت imports مربوط به NgModule کلاس AppModule معرفی می‌کنیم. برای این منظور به فایل src\app\app.module.ts مراجعه کرده و MyLibModule را به نحو ذیل اضافه می‌کنیم:
نکته‌ی مهمی که در اینجا باید به آن دقت داشت این است که هرچند در این پروژه، MyLibModule داخل پوشه‌ی projects\my-lib\src\lib قرار دارد، اما نباید مسیر نسبی آن‌را در اینجا ذکر کرد و باید صرفا نام پوشه‌ی my-lib واقع در پوشه‌ی node_modules را در اینجا در حین مسیر دهی import آن معرفی کرد (همانند تمام وابستگی‌های ثالث دیگر).
اما سؤال اینجا است که آیا این پوشه پس از build، داخل پوشه‌ی node_modules نیز کپی شده‌است؟ پاسخ آن خیر است و برای مدیریت خودکار آن، به صورت زیر عمل شده‌است:
اگر به فایل tsconfig.json اصلی و واقع در ریشه‌ی workspace دقت کنید، پس از اجرای دستور «ng generate library my-lib»، قسمت paths آن نیز به صورت خودکار ویرایش شده‌است:
معنای آن این است که هرگاه import ایی در برنامه به my-lib اشاره کند، کامپایلر TypeScript می‌داند که باید آن‌را از پوشه‌ی dist/my-lib دریافت و پردازش کند. به همین جهت در اینجا دیگر نیازی به کپی دستی این پوشه، به پوشه‌ی node_modules وجود ندارد.
به این ترتیب مسیر این import، چه در این پروژه‌ی محلی و چه برای کسانیکه پوشه‌ی dist/my-lib را به صورت یک بسته‌ی npm جدید دریافت کرده‌اند، یکی خواهد بود.
در ادامه اگر به فایل app.component.html مراجعه کرده و selector کامپوننت show-data را به آن اضافه کنیم:
می‌توان محتویات این کامپوننت دریافت شده‌ی از کتابخانه را مشاهده کرد.
توزیع کتابخانه‌ی ایجاد شده برای عموم
برای اینکه این کتابخانه‌ی تولیدی را در اختیار عموم، در سایت npm قرار دهیم، ابتدا باید کتابخانه را در حالت production build تولید و سپس آن‌را publish کرد:
سطر اول، کتابخانه‌ی my-lib را در حالت production تواید می‌کند. سپس به پوشه‌ی فایل‌های نهایی تولید شده وارد می‌شویم و دستور npm publish را صادر می‌کنیم.
البته دستور آخر نیاز به ایجاد یک اکانت در سایت npm و وارد شدن به آن‌را دارد. جزئیات بیشتر آن در اینجا.
Please open an issue in the library repository to alert its author and ask them to package the library using the Angular Package Format (https://goo.gl/jB3GVv).
مراحل ایجاد یک پروژه‌ی «کتابخانه» توسط Angular CLI 6.0
مرحله‌ی اول ایجاد یک پروژه‌ی کتابخانه، مانند قبل، توسط دستور ng new و ایجاد یک پروژه‌ی دلخواه جدید است:
ng new my-lib-test
پس از ایجاد پروژه‌ی my-lib-test توسط دستور فوق و وارد شدن به پوشه‌ی اصلی آن توسط خط فرمان، می‌توان با اجرای دستور زیر، پروژه‌های دیگری را به پروژه‌ی جاری افزود:
ng generate application my-app-name
ng generate library my-lib
همچنین یک پوشه‌ی جدید به نام projects نیز ایجاد شده و پروژه‌ی my-lib داخل آن قرار گرفته‌است.
فایل جدید public_api.ts
پس از ایجاد کتابخانه‌ی جدید «my-lib»، فایل جدیدی به نام projects\my-lib\src\public_api.ts نیز به آن اضافه شده‌است:
با این محتوا:
/* * Public API Surface of my-lib */ export * from './lib/my-lib.service'; export * from './lib/my-lib.component'; export * from './lib/my-lib.module';
برای مثال اگر فایل جدید projects\my-lib\src\lib\my-lib.models.ts را به این کتابخانه اضافه کنیم که شامل تعدادی مدل و اینترفیس قابل دسترسی توسط استفاده کنندگان باشد، باید یک سطر زیر را به انتهای فایل public_api.ts اضافه کنیم:
export * from './lib/my-lib.models';
این پروژه‌ی کتابخانه حتی به همراه فایل‌های package.json, tsconfig.json, tslint.json مخصوص به خود نیز می‌باشد تا بتوان آن‌ها را صرفا جهت این پروژه سفارشی سازی کرد.
ساختار my-lib.service پیش‌فرض یک پروژه‌ی کتابخانه
اگر به فایل projects\my-lib\src\lib\my-lib.service.ts دقت کنیم:
import { Injectable } from '@angular/core';
@Injectable({
providedIn: 'root'
})
export class MyLibService {
constructor() { }
} شاید بپرسید چرا؟ هدف اصلی از آن، بهبود فرآیند tree-shaking یا حذف کدهای مرده و استفاده نشده‌است. ممکن است سرویسی را تعریف کنید، اما در برنامه استفاده نشود. این حالت خصوصا در پروژه‌های کتابخانههای ثالث ممکن است زیاد رخ دهد. به همین جهت با ارائه‌ی این قابلیت، امکان حذف ساده‌تر سرویس‌هایی که در برنامه استفاده نشده‌اند از خروجی نهایی کامپایل شده، وجود خواهد داشت.
چگونه به پروژه‌ی کتابخانه‌ی جدید، یک کامپوننت جدید را اضافه کنیم؟
تمام دستورات Angular CLI، در اینجا نیز کار می‌کنند. تنها تفاوت آن‌ها، ذکر صریح نام پروژه‌ی مورد استفاده است:
ng generate component show-data --project=my-lib
البته در اینجا باید فایل my-lib.module.ts را اندکی ویرایش کرد و ShowDataComponent را به قسمت exports نیز افزود:
@NgModule({
imports: [
CommonModule,
HttpClientModule
],
declarations: [MyLibComponent, ShowDataComponent],
exports: [MyLibComponent, ShowDataComponent]
})
export class MyLibModule { } همچنین قسمت imports آن نیز به صورت پیش‌فرض خالی است. اگر نیاز است با ngIf کار کنید، باید CommonModule را در اینجا قید کنید و اگر نیاز است تبادلات HTTP وجود داشته باشد، ذکر HttpClientModule نیز ضروری است.
مرحله‌ی ساخت پروژه
پیش از استفاده‌ی از این پروژه‌ی کتابخانه، باید آن‌را build کرد:
ng build my-lib
پس از اجرای این دستور، خروجی ذیل مشاهده می‌شود:
Building Angular Package Building entry point 'my-lib' Rendering Stylesheets Rendering Templates Compiling TypeScript sources through ngc Downleveling ESM2015 sources through tsc Bundling to FESM2015 Bundling to FESM5 Bundling to UMD Minifying UMD bundle Remap source maps Relocating source maps Copying declaration files Writing package metadata Removing scripts section in package.json as it's considered a potential security vulnerability. Built my-lib Built Angular Package! - from: D:\my-lib-test\projects\my-lib - to: D:\my-lib-test\dist\my-lib
استفاده‌ی از کتابخانه‌ی تولید شده
پس از پایان موفقیت آمیز مرحله‌ی Build، اکنون نوبت به استفاده‌ی از این کتابخانه است. استفاده‌ی از آن نیز همانند تمام کتابخانه‌ها و وابستگی‌های ثالثی است که تا پیش از این از آن‌ها استفاده کرده‌ایم. برای مثال ماژول آن‌را در قسمت imports مربوط به NgModule کلاس AppModule معرفی می‌کنیم. برای این منظور به فایل src\app\app.module.ts مراجعه کرده و MyLibModule را به نحو ذیل اضافه می‌کنیم:
import { MyLibModule } from "my-lib";
@NgModule({
imports: [
BrowserModule,
MyLibModule
]
})
export class AppModule { } اما سؤال اینجا است که آیا این پوشه پس از build، داخل پوشه‌ی node_modules نیز کپی شده‌است؟ پاسخ آن خیر است و برای مدیریت خودکار آن، به صورت زیر عمل شده‌است:
اگر به فایل tsconfig.json اصلی و واقع در ریشه‌ی workspace دقت کنید، پس از اجرای دستور «ng generate library my-lib»، قسمت paths آن نیز به صورت خودکار ویرایش شده‌است:
{
"compilerOptions": {
"paths": {
"my-lib": [
"dist/my-lib"
]
}
}
} 
به این ترتیب مسیر این import، چه در این پروژه‌ی محلی و چه برای کسانیکه پوشه‌ی dist/my-lib را به صورت یک بسته‌ی npm جدید دریافت کرده‌اند، یکی خواهد بود.
در ادامه اگر به فایل app.component.html مراجعه کرده و selector کامپوننت show-data را به آن اضافه کنیم:
<lib-show-data></lib-show-data>
توزیع کتابخانه‌ی ایجاد شده برای عموم
برای اینکه این کتابخانه‌ی تولیدی را در اختیار عموم، در سایت npm قرار دهیم، ابتدا باید کتابخانه را در حالت production build تولید و سپس آن‌را publish کرد:
ng build my-lib --prod cd dist/my-lib npm publish
البته دستور آخر نیاز به ایجاد یک اکانت در سایت npm و وارد شدن به آن‌را دارد. جزئیات بیشتر آن در اینجا.
1. Using xproj & csproj files together
2. Building for deployment
3. NetStandard vs NetCoreApp1.0
4. IIS is dead, well sort of
5. HttpModules and HttpHandlers are replaced by new “middleware”
6. FileStream moved to System.IO.FileSystem ???
7. StreamReader constructor no longer works with a file path
8. Platform specific code… like Microsoft specific RSA
9. Newtonsoft changed to default to camel case on field names 🙁
10. Log4net doesn’t work and neither do countless other dependencies, unless you target .NET 4.5!
11. System.Drawing doesn’t exist
12. DataSet and DataTable doesn’t exist
13. Visual Studio Tooling
14. HttpWebRequest weird changes
15. Creating a Windows Service in .NET Core
2. Building for deployment
3. NetStandard vs NetCoreApp1.0
4. IIS is dead, well sort of
5. HttpModules and HttpHandlers are replaced by new “middleware”
6. FileStream moved to System.IO.FileSystem ???
7. StreamReader constructor no longer works with a file path
8. Platform specific code… like Microsoft specific RSA
9. Newtonsoft changed to default to camel case on field names 🙁
10. Log4net doesn’t work and neither do countless other dependencies, unless you target .NET 4.5!
11. System.Drawing doesn’t exist
12. DataSet and DataTable doesn’t exist
13. Visual Studio Tooling
14. HttpWebRequest weird changes
15. Creating a Windows Service in .NET Core
