WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#35338 closed defect (bug) (worksforme)

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

Reported by: henry.wright Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords:
Focuses: Cc:
PR Number:

Description

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.

Attachments (1)

35338.diff (526.6 KB) - added by henry.wright 4 years ago.

Download all attachments as: .zip

Change History (9)

#1 @dd32
4 years ago

That's not expected.

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

#2 @dd32
4 years ago

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

#3 @henry.wright
4 years ago

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.

@henry.wright
4 years ago

#4 @netweb
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed
  • Version trunk deleted

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.

This ticket was mentioned in Slack in #core by dd32. View the logs.


4 years ago

#6 follow-up: @henry.wright
4 years ago

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

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

#7 in reply to: ↑ 6 @netweb
4 years ago

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.

#8 @henry.wright
4 years ago

Thanks for clarifying, info very much appreciated :)

Note: See TracTickets for help on using tickets.