Generators try to copy .DS_Store on OSX, if directory is non-pristine

[xml]

With [email protected] on Node 5.7.0, running a generator is producing the following non-fatal errors (which do not seem to otherwise interfere with execution):

> redux g dumb DumbExample

  info: installing blueprint...
  error: Not writing file.  File already exists at: /path/to/project/.DS_Store
  error: Not writing file.  File already exists at: /path/to/project/src/.DS_Store
  error: Not writing file.  File already exists at: /path/to/project/src/components/.DS_Store
  create: /path/to/project/src/components/DumbExample/.DS_Store
  create: /path/to/project/src/components/DumbExample/DumbExample.component.js
  create: /path/to/project/src/components/DumbExample/DumbExampleComponent.spec.js
  info: finished installing blueprint.

It doesn't happen at first, if I don't touch anything in /blueprint. But any time you use the OSX Finder to modify the file structure of a directory, it creates a .DS_Store file. So, even if you just create an empty folder in a blueprint folder, then immediately delete it, you have a .DS_Store. And if people use the Finder at all to take advantage of the potential to customize the blueprints... they'll have a ton of them.

Thereafter, the generators try to copy all those .DS_Store files along with the real blueprint files, when instantiating a new module. Note that it happens at multiple levels along the path, as in the example above.

Might junk be a possible solution?

[anithri]

Since walk-dir is being used to generate the list of files for a blue print, we should be able to change

In src/models/blueprint.js
this._files = walkSync(filesPath); to this._files = walkSync(filesPath, { ignore: ['.DS_Store] })
an additional test will be needed in test/models/blueprint.test.js

[jamesr73]

Can we put the array of ignores in blueprintrc with .DS_Store as the default entry?

[anithri]

I think that's a good idea. full names or patterns do you think?

[jamesr73]

Since walk-sync supports globs makes sense to expose that directly. Simply pass the array in rc directly to walkSync.

[anithri]

Passing it to walk-sync works for me, but getting that setting to the right place takes a bit of thought.

And more urgently I think, we need to resolve #101 first.

And then we need to figure out the best way to get settings to blueprints.

• pass the entire projectSettings object to it. Extend projectSettings to make it easy to extract specific settings
• pick a subset of projectSettings and pass just that to the blueprint.
• relay on passing args to methods to get the specialized info it needs.

projectSettings is a God object that everybody needs a piece of. But the structure of the cli and the lack of lengthy lifetime render most concerns about God Objects moot. It also gives blueprint authors more flexibility on how they consume the settings data. some sort of .mySettings() which does what getBlueprintSettings does now.

[anithri]

This will be set as so.

# .blueprintrc
{
  ...
  "bp": {
    "common": {
      ...
      "files": {
        "blacklist": [
          ".DS_Store",
          ".gitkeep"
        ] } } }