Modified source files after cloning the development repository and then running npm install and grunt build

[henry.wright]

After cloning the Git development repository, then running npm install and grunt build, I get modified files in the src/ directory.

git clone git://develop.git.wordpress.org/ develop
cd develop
npm install
grunt build

Then doing git status gives:

modified:   src/wp-includes/js/media-audiovideo.js
modified:   src/wp-includes/js/media-grid.js
modified:   src/wp-includes/js/media-models.js
modified:   src/wp-includes/js/media-views.js

Is this right? I wasn't expecting source files to be modified.

[dd32]

That's not expected.

After following the exact commands listed here, I get a clean git status. What environment are you running it on?

[dd32]

Can you also post a diff of the changes you're seeing?

[henry.wright]

I'm running Ubuntu 14.04 on armhf architecture (not sure if using a non-Intel processor matters?). Sure, I'll attach the .diff. Let me know if you need anything else.

[netweb]

If you run grunt watch or possibly a combination of the browserify task or a failed grunt build task you'll end up with those 4 files with a modified status. When "watching" the files with grunt watch JS source maps are created which is what your seeing in 35338.diff​.

Here's my output on a fresh Git checkout after running npm install and grunt build and then running grunt watch:

netweb@MacBook ~/dev/develop.git.wordpress.org [master]
$ grunt watch
Running "watch" task

Running "browserify:audiovideo" (browserify) task
>> Bundle src/wp-includes/js/media-audiovideo.js created.

Running "browserify:grid" (browserify) task
>> Bundle src/wp-includes/js/media-grid.js created.

Running "browserify:models" (browserify) task
>> Bundle src/wp-includes/js/media-models.js created.

Running "browserify:views" (browserify) task
>> Bundle src/wp-includes/js/media-views.js created.

Running "_watch" task
Waiting...
^C

netweb@MacBook ~/dev/develop.git.wordpress.org [master]
$ gs
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   src/wp-includes/js/media-audiovideo.js
        modified:   src/wp-includes/js/media-grid.js
        modified:   src/wp-includes/js/media-models.js
        modified:   src/wp-includes/js/media-views.js

no changes added to commit (use "git add" and/or "git commit -a")

netweb@MacBook ~/dev/develop.git.wordpress.org [master]
$ 

To resolve this run grunt precommit which will clean up after the above.

It would be great if grunt watch had a more graceful exit procedure rather than having to CTRL-C out of it but sadly grunt-contrib-watch does not have anything like this at this stage.

Closing this as worksforme, which is by no means is this an ideal resolution either.

[henry.wright]

@netweb running grunt precommit resulted in a clean working copy.

Why is grunt precommit preferable to git checkout -- .?

[netweb]

Replying to henry.wright:

@netweb running grunt precommit resulted in a clean working copy.

Why is grunt precommit preferable to git checkout -- .?

The key here is to have a Grunt task run grunt browserify to restore the files to the "pre watched state", grunt precommit includes that task in its set of tasks run.

I suggested grunt precommit over grunt browserify because we should try to minimise the number of grunt tasks we need to remember, grunt build, grunt test, and grunt precommit cover 99% of the build tool functionality, so only having remember 3 tasks over ~20 tasks is preferable.

As to why not use git checkout --.... you could indeed use that to revert the changes, I suggested the Grunt task because it was Grunt that actually changed the files, so we can use Grunt again to restore these same files.

[henry.wright]

Thanks for clarifying, info very much appreciated :)