main static file copy

[zhanglongqi]

It seems the files option is electron-builder.json define the file from build folder to dist\xxx-unpacked\resources\app because I found out the main static files are not copied from src\main\static to build\main\static on win11, so I added below code to function buildMain() in build.js

    FileSystem.cpSync(Path.join(__dirname, '..', 'src', 'main', 'static'), Path.join(__dirname, '..', 'build', 'main', 'static'), {recursive:true});

Did you encounter this issue?

[Deluze]

This is unintended.

The following line of code is being fired when you spin up the dev server:

FileSystem.cpSync(
  Path.join(__dirname, '..', 'src', 'main', 'static'), 
  Path.join(__dirname, '..', 'build', 'main', 'static'), 
  { recursive: true }
);

The electron-builder config is ignored when you work in a dev environment, electron-builder config is only used when you actually build the application for production / distributing. I didn't encounter an issue with static files, I'm also on W11/MacOS. So your PR (#18) is incorrect, following the README on how static files should work.

A little side note that is missing from the README is that static files are only copied over ONCE after running npm run dev, if you added new files to the static directory you will need to restart your dev server. This is to prevent copying over static (potentionally big) files after every change.

I'll close this issue & PR with the assumption of that you didn't restart your dev server. If that's not the case and there's actually another issue going on please re-open this 😄 I'll also extend the readme with more details about this behavior.

[zhanglongqi]

Thanks for your clarification. Now I know it's because I develop the application on mac and package on windows, I run npm run build directly instead of running npm run dev, that's why the static files are never being copied.

[zhanglongqi]

For the PR https://github.com/Deluze/electron-vue-template/pull/18, actually we do not need

 {
      "from": "src/main/static",
      "to": "static",
      "filter": ["**/*"]
},

because the "build/main/**/*", already cover all of the main static files already .

[immafrady]

A little side note that is missing from the README is that static files are only copied over ONCE after running npm run dev, if you added new files to the static directory you will need to restart your dev server. This is to prevent copying over static (potentionally big) files after every change.

@Deluze aha. so that's reason when i edited some template files in static folder, electron restarted, but nothing change, makes me confusing.

With this feature still exist, I think dev-server.js should stop listening change on static folder

    Chokidar.watch(Path.join(__dirname, '..', 'src', 'main')).on('change', () => {
        restartElectron();
    })

[Deluze]

Thanks for your clarification. Now I know it's because I develop the application on mac and package on windows, I run npm run build directly instead of running npm run dev, that's why the static files are never being copied.

If someone runs npm run build instead of npm run dev, build/main/static will actually not exist. The build script does not copy the static files, you're correct. Electron Builder pulls the static files directly from the src/main/static.

This would be the new way of referencing static files with your PR (& this wouldn't work on the dev server):

const path = app.getAppPath() + '/build/main/static/myFile.txt'

But I expect that all static files will be available in app.getAppPath() + '/static/...', and this should always work independently of OS & environment (dev, build).

This also works in your situation @zhanglongqi. Perhaps your manual copying breaks this?

[Deluze]

You made me think of a potentially better solution @immafrady 👍

We could check if the change happened to one of the static files. Copy only and only the static file that got changed & restart Electron after. When a change has been made outside of the static files, we don't have to copy anything explicitly.

Update: Already implemented now in 4f3d845aef01df0f54f581981b2aa7fc46c0f0fc