Barrels files updated with wrong content on repetitive run if `noHeader` flag enabled

[aborovsky]

Description
Barrels were generated already with the noHeader flag enabled.
When one will rerun barrelsby with delete flag enabled, barrels files are not deleted and moreover: will be reused.
As a result, each barrel file will be updated with content:

export * from './index';

To Reproduce
Steps to reproduce the behavior:

1. SetupTS project with package.json dependency: "barrelsby": "2.5.1"

• mkdir barreslsby-issue
• cd barreslsby-issue
• npm init (just accept default values)
• npm i barrelsby@2.5.1 --save-exact
• npm i typescript
• add tsconfig.json at the project's root:

{
  "compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "skipLibCheck": true
  },
  "include": ["src"]                
}

• mkdir -p src/directory1
• touch ./src/directory1/example.ts

2. Add .barrelsby.json configuration file at the project's root:

{
  "directory": [
    "./src/directory1",
    "./src"
  ],
  "noHeader": true,
  "delete": true
}

3. Run local barrelsby with command: ./node_modules/.bin/barrelsby -V --config .barrelsby.json
4. Check proper content for 2 generated files:

• cat ./src/index.ts, gives: export * from "./directory1/index";
• cat ./src/directory1/index.ts, gives: export * from "./example";

5. Rerun barrelsby with same command: ./node_modules/.bin/barrelsby -V --config .barrelsby.json
6. Check wrong content for 2 updated files:

• cat ./src/index.ts, gives: export * from "./index";
• cat ./src/directory1/index.ts, gives: export * from "./index";

Expected behavior
When noHeader flag enabled, barrelsby should delete barrels found even if it has no autogenerated header inside.

Environment:

• OS: macOs 13.2.1 (22D68)
• Node Version: v19.8.1
• Typescript Version: 4.8.2
• Barrelsby Version: barrelsby@2.5.1
  • resolved https://registry.yarnpkg.com/barrelsby/-/barrelsby-2.5.1.tgz#3aed013f6c16d04051b0aa708f7f68efb016b916
  • integrity sha512-SErpMd91jzrjeS1F5X96AmqaQzcKaxpVVHj6EX6EWTNP00HJxg5+Nb0Avbpo+xEWPyDuflgoiH+iRKDU7O44wg==

Additional context
Relates to: #153 (comment)