空のNativeScriptプロジェクトのデフォルト構造は、app、platforms、node_modulesディレクトリを 含むルートフォルダー、およびpackage.jsonファイルで構成されます。
myApplication/
└── app
├── App_Resources
└── ...
├── node_modules
├── platforms
└── package.json初期テンプレート、プログラミング言語（JavaScriptまたはTypeScript）、またはアプリケーションで使用しているプラグインに基づいて、プロジェクトに存在できる他のディレクトリと構成ファイルがいくつかあります。 この記事では、NativeScriptプロジェクトに常に存在するファイルとフォルダー、およびアプリの開発中に遭遇する可能性のあるより一般的なものについて説明します。
プロジェクトのルートにあるappディレクトリはプロジェクトの開発スペースです。 すべての共通およびプラットフォーム固有のコードをこのディレクトリに配置します。 アプリのビルドの準備が整うと、NativeScriptツールは関連するコンテンツを各ターゲットプラットフォームのプラットフォーム固有のフォルダーにコピーします。
appディレクトリでは、プラットフォーム固有のファイルを使用して、ターゲットプラットフォームごとにカスタマイズされた機能とデザインを提供できます。
ファイルがプラットフォーム固有であることを示すには、ファイル名がname.ios.extensionまたはname.android.extensionの形式であることを確認してください。
例：main.ios.js、main.android.js
共有機能を開発したり、共通ファイルで設計することもできます。ファイルが一般的であることを示すには、ファイル名に.androidや.iosが含まれていないことを確認してください。
appフォルダーには、App_Resourcesディレクトリーもあります。
これはセカンダリのpackage.jsonファイルです。 このファイルでは、アプリのエントリポイントファイルを指定し、NativeScriptランタイムの動作を構成できます。 以下は、基本的なセカンダリpackage.jsonファイルの例です。
{
"main": "app.js",
"discardUncaughtJsExceptions": true,
"android": {
"v8Flags": "--expose_gc",
"forceLog": true
},
"ios": {
"jscFlags": "--dumpOptions=2 --validateOptions=1"
}
}通常、ネイティブAPIから呼び出されたJavaScriptコードからの未処理の例外は、スタックトレースを表示してアプリケーションをクラッシュさせます。 このようなクラッシュを防ぎたい場合は、discardUncaughtJsExceptionsフラグを使用してこの動作をオーバーライドできます。
破棄された例外はすべて、application.discardedErrorEventを起こします。 global.__onDiscardedErrorに1つの引数を持つ関数を割り当てることで、 受信したDiscardedErrorEventDataインスタンスを使用するか、 NativeScriptErrorインスタンスとして例外を受け取る ことにより、アプリで処理できます。 通常、例外をログに記録したり、分析処理へ報告したりします。
例：
var application = require("application");
application.on(application.discardedErrorEvent, function (args) {
const error = args.error;
console.log("Received discarded exception: ");
console.log(error.message);
console.log(error.stackTrace);
console.log(error.nativeException);
//report the exception in your analytics solution here
});Androidランタイムに固有のフラグの説明については、Androidカスタムフラグの記事を参照してください。
iOSランタイムに固有のフラグの説明については、iOSカスタムフラグの記事を参照してください。
このApp_Resourcesフォルダーには、アプリケーションのプラットフォーム固有のリソース（アイコン、構成ファイルなど）が含まれています。 NativeScriptツールによって使用される構成ファイルは、Android用はApp_Resources/Android/src/main/AndroidManifest.xml、iOS用はApp_Resources/iOS/Info.plistです。
また、App_Resources/iOS/build.xcconfigまたはApp_Resources/Android/app.gradleを変更して、 iOSプラットフォームとAndroidプラットフォームのビルドプロパティを追加または削除できます。
ビルドを開始したり、プロジェクトにターゲットプラットフォームを追加したとき、platformsディレクトリが作成されます。 NativeScriptツールは、それぞれのプラットフォーム名で新しいサブディレクトリを作成します。 これらのサブディレクトリには、プラットフォームのネイティブSDKを使用したネイティブ開発に必要なプラットフォーム固有のプロジェクト構造があります。 プロジェクトのビルドの準備が整うと、NativeScriptツールは、関連するコンテンツをappディレクトリから各ターゲットプラットフォームのプラットフォーム固有のサブディレクトリにコピーします。
prepare <Platform>プロセス中にNativeScript CLIによってappディレクトリのコンテンツで上書きされるため、編集しないでください。
プロジェクトのルートディレクトリにあるメインのpackage.jsonには、アプリケーション、その依存関係、その他の役立つ情報に関する詳細が含まれています。
作成者(author)、説明(description)、バージョン(version)などの一般的なnpm package.jsonプロパティを設定するか、
依存関係(dependencies)とdevDependencies属性を変更して、アプリが依存するnpmパッケージとNativeScriptプラグインを指定できます。
ルートのpackage.jsonには、nativescriptオブジェクト内に配置されるいくつかのNativeScript固有のプロパティも含まれます。
基本的なメインpackage.jsonファイルの例を次に示します。
{
"nativescript": {
"id": "org.nativescript.myApplication",
"tns-android": {
"version": "5.0.0"
},
"tns-ios": {
"version": "5.0.0"
}
},
"description": "My NativeScript Application",
"license": "MIT",
"repository": "https://github.com/myApplication",
"dependencies": {
"nativescript-theme-core": "~1.0.4",
"tns-core-modules": "~5.0.0"
},
"devDependencies": {
"nativescript-dev-typescript": "~0.7.0",
"typescript": "~2.7.2"
},
"readme": "My NativeScript Application"
}hooksフォルダーは、プロジェクトが適切に機能するためにフックを必要とするプラグインに依存している場合にのみ存在します。 フックは、拡張可能なNativeScript CLIコマンドの動作を変更または拡張するために使用される実行可能なコードまたはNode.jsスクリプトです。 フックとNativeScriptでフックを使用する方法の詳細については、CLIの拡張を参照してください。
フックを持つ、より一般的なプラグインのいくつかはnativescript-dev-webpack、nativescript-dev-typescriptおよびnativescript-dev-sassです。
tsconfig.jsonファイルは、TypeScriptを使用するプロジェクトにのみ存在します。 このファイルは、TypeScriptをJavaScriptに変換する際のガイドとして機能します。 さまざまなコンパイラオプションを構成することで、変換プロセスを微調整できます。 tsconfig.jsonの詳細については、TypeScriptの公式ドキュメントを参照してください。
nsconfig.jsonは、メインのpackage.jsonファイルと同じレベルのルートプロジェクトディレクトリにあるオプションの構成ファイルです。 このファイルにより、ユーザーはアプリケーションの構造を変更し、HMR開発者機能を有効/無効にすることができます。 使用可能な構成は、appPath、appResourcesPath、useLegacyWorkflowです。
すべてが期待どおりに機能するためには、パス（appPathおよびappResourcesPath）は
プロジェクトルート（package.jsonファイルとplatformsディレクトリが配置されている場所）に対して相対的である必要があります。
appPathを省略すると、CLIはアプリケーションファイルがプロジェクトフォルダー内の app というフォルダー内にあると想定します。
appResourcesPathが省略された場合、CLIはそれらがデフォルトの場所（アプリファイルの残りを含むフォルダー内の App_Resources と呼ばれるフォルダー）にあると想定します。
nsconfig.jsonファイルを使用するには、次の要件を満たしていることを確認する必要があります。
useLegacyWorkflowオプションには、NativeScript CLI >= 5.3.0が必要プロジェクトが /d/work/myApplication にあると仮定しましょう。
/d/work/myApplication/app にあり、リソースは /d/work/myApplication/app/App_Resources にあります。/d/work/myApplication/code/src にアプリが、 /d/work/myApplication/code/src/App_Resources にリソースが作成されます。
{
"appPath": "code/src"
}/d/work/myApplication/app にアプリが、 /d/work/myApplication/resources にリソースが作成されます。
{
"appResourcesPath": "resources"
}/d/work/myApplication/code/src にアプリが、 /d/work/myApplication/resources にリソースが作成されます。
{
"appPath": "code/src",
"appResourcesPath": "resources"
}useLegacyWorkflowをfalseに設定すると、デフォルトでHMRが有効になります（HMRを使用するために追加のフラグを渡す必要はありません）。 省略した場合のデフォルト値はtrueです（拡張HMRを使用しない標準のライブ同期機能）。
{
"useLegacyWorkflow": false
}