SPFx - Understanding the File Structure in SharePoint Framework :: SPFX 1.14

 

SPFx - Understanding the File Structure in SharePoint Framework :: SPFX 1.14

Shows Solution structure of the SharePoint framework.  Yeoman SharePoint generator makes it easy for the developer to kickstart the SPFx development without wasting time in creating the folder and file structure. 

Below are important files in SPFx Solution:

When we run the command to scaffold the solution using Yeoman generator, it will create a file and folder structure as shown below:

Below are the details of each folder and respective files that are needed for SPFx development.

A) .vscode folder: 

It is the default folder created by Visual Studio. These files contain the debugging and task configurations. This folder contains three files as below:

1. extensions.js : This file does not relate to SPFx. It only indicates the list of extensions that you have installed in your VS Code.

 2. launch.json: This file contains the workbench configurations. We can define the location for local and SharePoint hosted workbench. We can easily debug the SPFx code using the workbench. In our upcoming videos, we will see how we can debug the SharePoint Framework solution using the workbench.

3. settings.json: settings.json is not related to SPFx and this file defines the user preferences like white spaces, code font size, etc. You can ignore this file as it is not important.

 B) config folder

This folder contains a set of JSON files that help us to define the configurations for our SPFx solution. These configurations include webparts entry points, workbench initial page, etc. config folder contains all JSON files as below

1. config.json: This is one of the main files in the SPFx solution. It contains a list of all the webparts present in your solution. It tells about the: 

    a. entry point for each webpart: so that webpart knows from where exactly it needs to start

    b. location of the manifest file for each webpart: manifest file has all the information about the webparts like webpart id, name, description, etc. 

    c. location of localized resources for each webpart: localized resources serve your webpart in different languages. 

    d. you can also define the external js files if you want them to load with your solution. For example, you can put the path of jquery files as shown below under externals as shown in the below picture:

2. copy-assets.json: When you want to host your webpart using CDN you can take the help of this file. Here we define the CDN path of the js files that will get generated when we run the bundle command. You can then go to this path from your solution and copy the .js files to CDN. 

You can check more details about this from the below link:

 Deploy SPFx webpart with CDN

 3. deploy-azure-storage.json: This is the file that contains your Azure Storage account details. The SPFx webparts are mainly deployed on one of the below CDN (Content Delivery Network) options:

• Azure CDN (This article)
• Office 365 Public CDN
• SharePoint Library in your tenant

When you need to deploy your webpart to Azure CDN, you need to configure the Azure storage account details in this JSON file.

 4. package-solution.json: This file contains details about the location for the package that will get generated when we build the solution. This file also has the configurations like webpart name, description, version, etc.

 5. serve.json: This file contains the initial page load URL when you run the webpart using local workbench.

 6. write-manifests.json: You can specify the CDN path if you have decided to host the SPFx app external CDN other than Office 365 public CDN.

 C. node_modules:

Contains JavaScript modules downloaded by Node.js

When we run the npm install, all the required external modules will get downloaded and saved in the node_modules folder. This folder is only needed for build purposes. We do not check-in this folder in the repository, as it is not a customized folder. When we clone the repository and run the command npm install, this folder will get created with all required modules.

 All the required external modules that we have used in our solution can be found under the package.json file.

 D. src:

This is the actual source folder where our webparts and extensions code goes in. Under the src folder, you can find the webpart folder for webparts and the extension folder for extensions. In our upcoming articles, we will learn SPFx webparts and extensions in detail.

 1. loc: This folder contains one interface file and one or more language localization files like en-us.js, de-DE.js, etc. SPFx provides an ability to load the webpart in different languages. You can define the language strings in these files.

 2. webpart.manifest.json: Each webpart has its own manifest file. It contains the configuration related to webpart name, webpart description, group name, webpart icon, etc.

 3. webpart.module.scss: This is a styling file for your webpart. It is called SCSS (Sassy CSS) an advanced version of CSS. 

 4. webpart.ts: This file defines the entry point for the webpart. This file has one webpart class which extends BaseClientSideWebPart. BaseClientSideWebPart provides the basic functioning of the webpart. This file also contains the webpart property pane configurations.

 5. Components folder: This folder will be available only if you use React as a framework. This folder will contain the state and props interface files, .scss file and one important file known as webpart.tsx. 

     5.1 webpart.tsx: This file mainly contains the HTML for your webpart. This also includes the function calling along with the react lifecycle. You can update the state of the webpart with the help of this file. This file is only available if you use React in your webpart.

 E. .gitignore: 

This file contains all the files that need to be ignored by git. That means when you check-in the code, the files mentioned in this file will be ignored and not be uploaded to the repository.

 F: .yo-rc.json

When we run the Yeoman generator on a brand new folder, it creates the project & the component. This file indicates the Yeoman version and the environment with which we have created the solution. This version is also known as the SPFx version. If you run it again, it detects (by the presence of the .yo-rc) file & skips all the questions global to the project & goes straight to the questions for creating a component

 G. gulpfile.js

The gulp tasks that we use to run the application are written/referenced in this file.

 H. package-lock.json

It stores an exact, versioned dependency tree rather than using starred versioning like package.json itself (e.g. 1.0.*). This means you can guarantee the dependencies for other developers or prod releases, etc. It also has a mechanism to lock the tree but generally will regenerate if package.json changes.

 Reference: https://stackoverflow.com/a/44297998

 I. package.josn

All npm packages contain a file, usually in the project root, called package.json - this file holds various metadata relevant to the project. This file is used to give information to npm that allows it to identify the project as well as handle the project's dependencies.

 It can also contain other metadata such as a project description, the version of the project in a particular distribution, license information, even configuration data - all of which can be vital to both npm and to the end users of the package. 

 J. tsconfig.json

The presence of a tsconfig.json file in a directory indicates that the directory is the root of a TypeScript project. The tsconfig.json file specifies the root files and the compiler options required to compile the project.

 K.tslint.json

tslint checks TypeScript code for readability, maintainability, and functionality errors. We can define the rules for which the code checks for warnings and errors for build.