Discussion on Rethinking File Structure

[cawa-93]

I'm thinking about how to organize files and directories. Now I see that the file structure that exists at the moment may not be very convenient.

I'm considering the following file organization:

├───bin
├───main
│   ├───dist
│   ├───src
│   ├───test
│   └───types
├───preload
│   ├───dist
│   ├───src
│   ├───test
│   └───types
└───renderer
    ├───dist
    ├───src
    ├───tests
    └───types

This is similar to how monorepo are organized. But this is not a monorepo.

If you have any thoughts or feedback on this idea - welcome to the discussion.

Probable Benefits:

• Theoretically, this should simplify the work on the project. When working on one module, you do not have to jump on different levels of directories. Everything related to one module will be at hand.

Possible disadvantages:

• Theoretically, it can be difficult to understand "what is this module" looking only at the file name index.ts because different modules will have files with the same names.
• I'm not sure how easy and efficient it is to configure an electron-builder to work with such a file structure.

Questions for consideration:

• How to work with npm:
  • Are there any benefits to using workspaces?
  • Does it make sense to divide the lists of dependencies for different modules?

[xiaohulu]

1. Where is the typescript interface shared by main and preload？

[cawa-93]

Hmmm. I didn't think about it. Could you describe some use cases?

[xiaohulu]

For example, a request module which based on electron net.

I create a request.ts at main directory

import { net } from 'electron';

// define RequestConfig interface first time
export interface RequestConfig {
  url?: string;
  baseURL?: string;
  method?: 'POST' | 'GET' | 'PUT' | 'DELETE';
  data?: any;
  responseType?: 'json' | 'text';
  headers: any;
}

export function request<T = any>(config: RequestConfig): Promise<NetResponse<T>> {
    // use electron net to send http request and receive response
   //...
}

Use ipcMain to handle, below code at main direactory

function initRequest() {
  ipcMain.handle('request', async (event, config: RequestConfig) => {
    return await request(config);
  });
}

Then I create request.ts at preload directory.

import { ipcRenderer } from 'electron';

// define RequestConfig twice
export interface RequestConfig {
  url?: string;
  baseURL?: string;
  method?: 'POST' | 'GET' | 'PUT' | 'DELETE';
  data?: any;
  responseType?: 'json' | 'text';
}

function request<T = any>(config: RequestConfig): Promise<NetResponse<T>> {
  return ipcRenderer.invoke('request', config);
}

I use this api at renderer process.

Now, I create an interface under the main and preload directories respectively.

[cawa-93]

Why you not use ClientRequestConstructorOptions interface from electron?

[xiaohulu]

I want to use electron net at production environment, use axios at development environment. So need to define an interface to keep the two's parameter interface same.

[cawa-93]

This is a good remark. In fact, nothing prevents you from importing types from the main entry point, although it's a bit ugly. For this purpose the type of a configuration is put to take out in a separate file

import type { RequestConfig } from /@/../main/requestConfig.ts

[luffynando]

I think that the current structure is concise and allows to separate both the configuration files and the main part or the core of the operation. Possibly with the new structure there may be confusion.

[cawa-93]

After spending some time, I found that this template was not very suitable for the current node ecosystem. There are inconveniences and problems when using different tools:

• Almost all libraries search for the configuration file in the root directory. Therefore, when placing a configuration in the config folder, you cannot "just use" the library, and you must clearly set the path to the configuration each time.
• Some libraries search for the configuration file EXCLUSIVELY in the root directory, and do not have the option to change this behaviour. That violates the principle of "All configurations in one place."
• Using eslint, typescript, postCSS, etc., we are forced to insert additional configuration files in the directory src, which violates the principle of "only source".

For these reasons, I decided to change the structure of this template and began work on a new version. In the new edition, all global things, such as configuration files, tests or types, are in the root directory. Draft is here.

All module-specific configs, tests, and types are located in subfolders of a specific module.

Working with such a structure should be easier and it should be more flexible.