-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make the build / run / test process Windows-compatible by adding NPM scripts for all the tasks. #13536
Conversation
outputOptions; | ||
|
||
if ( 'development' === config( 'env' ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like bundleEnv
wasn't used at all before. Why do we want to exit early for development
env?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the Makefile
, the bundler is only run when env != development
, here: https://github.com/Automattic/wp-calypso/blob/master/Makefile#L188
That (conditionals) is hard to replicate in NPM scripts, so I opted for always running the bundler (here) and exit early if env == development
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool 👍 Now it makes perfect sense :)
@@ -8,9 +8,10 @@ | |||
|
|||
var async = require( 'async' ), | |||
camelCase = require( 'lodash/camelCase' ), | |||
config = require( 'config' ), | |||
config = require( '../../config' ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it break otherwise? This config thing is really confusing :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it doesn't break. I probably made this change before I figured out how NODE_PATH
works. I've just reverted it to remove some noise.
7cdd335
to
17c750b
Compare
I testes the following command on macOS Sierra:
Everything works as expected. I'm wondering if pre commands always work properly. In the case of
|
That's expected. It is executing |
It needs more testing, but otherwise it looks awesome 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had very minor comments, but otherwise the code looks good.
bin/trim-shrinkwrap.js
Outdated
*/ | ||
|
||
const fs = require( 'fs' ); | ||
const shrinkwrap = require( __dirname + '/../npm-shrinkwrap.json' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really have to use __dirname
here? What about the following?
const shrinkwrap = require( '../npm-shrinkwrap.json' );
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, it's not needed. Fixed.
package.json
Outdated
@@ -32,6 +32,7 @@ | |||
"bounding-client-rect": "1.0.5", | |||
"browser-filesaver": "1.1.0", | |||
"chalk": "1.0.0", | |||
"check-node-version": "2.0.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be a typo: the latest version is 2.1.0
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a typo, 2.0.1
was the latest version until 2 days ago :)
Bumped to the latest.
package.json
Outdated
@@ -61,11 +63,12 @@ | |||
"flux": "2.1.1", | |||
"fuse.js": "2.6.1", | |||
"get-video-id": "2.1.4", | |||
"globby": "3.0.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about using the latest version, which is 6.1.0
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one may have been a typo... 3.0.1 is quite old.
Bumped to the latest.
I tried on Ubuntu and I could run Calypso without any apparent issue. I tried the following commands:
There is this strange error about Yarn when I run
|
Did you try it after my latest change? It was a bug that was fixed in the latest version of It's not really an error because we don't have a |
No I didn't test that change. Glad to hear it was fixed! |
@DanReyLop This PR needs a rebase |
@DanReyLop This PR needs a rebase |
So... is this ready to ship? 2 people tested it in OS X and Ubuntu with no apparent issues, and CI is passing (using the new build commands). |
@DanReyLop This PR needs a rebase |
@DanReyLop This PR needs a rebase |
If there is no objection, I plan to merge this PR next Wednesday at noon UTC. Since |
I'll give it another try on Monday or Tuesday :) |
Tested again on Mac OS X:
|
When loading http://calypso.localhost:3000/read/a8c I see the following error on JS console: It probably needs another rebase with master. |
After executing Technically |
@@ -5,9 +5,9 @@ test: | |||
pre: | |||
- ? | | |||
# make the build-server and i18n string data in parallel | |||
if [[ "$CIRCLE_NODE_INDEX" == 0 ]]; then NODE_ENV=test make build-server; fi | |||
if [[ "$CIRCLE_NODE_INDEX" == 0 ]]; then NODE_ENV=test npm run build-server; fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we revert changes made to Circle CI config file and put them in the follow up PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, but... why? CircleCI is passing using the new build system, which gives some reassurance that it works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should double check why linter fails locally and remove changed applied to Circle CI config file. We should also make sure Calypso works properly. It is probably some unlucky coincidence that Reader errors.
Once this is done I'm happy to approve this patch.
Done :)
I've merged with |
# Conflicts: # npm-shrinkwrap.json # package.json
"test-test": "cross-env NODE_ENV=test NODE_PATH=test:client TEST_ROOT=test node test/runner.js", | ||
"test-test:watch": "nodemon -e js,jsx --exec npm run -s test-test", | ||
"translate": "i18n-calypso --format pot --output-file ./calypso-strings.pot -e date \"**/*.js\" \"**/*.jsx\" \"!build/**\" \"!node_modules/**\" \"!public/**\" \"!client/extensions/**\"", | ||
"update-deps": "npm run -s rm -- node_modules && npm run -s rm -- npm-shrinkwrap.json && npm install && npm install && npm shrinkwrap --dev" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DanReyLop Sorry, I missed this earlier, but do you mind adding a --no-optional
flag to each of the install
commands in a follow up PR? eg npm install --no-optional
Currently this will add fsevents to the shinkwrap that will throw errors in the docker image.
See also #5386
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that still a problem? npm 3.10.9
and lower had that issue, but it was fixed in 3.10.10
(which is what we're using). See: https://github.com/npm/npm/releases/tag/v3.10.10
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I'll gladly remove yet another hack on my next PR :)
I never had the "double install" problem, so I wasn't sure how did it manifest itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After we updated to npm 3, it used to show up very consistently after you removed node_modules + the shrinkwrap. Basically you'd npm install
and then a second npm install
would install more stuff!
Looks like it was closed out a while ago, see: npm/npm#10727
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gwwar Just to be on the safe side, I won't remove the second npm install
. According to this PR: npm/npm#12811 (comment) the fix was included in npm 4.0.5
, so we'll better wait till October :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me 👍
Was the desktop app build tested with this PR? I'm having problems building on CircleCI but not on my macOS machine. |
@astralbodies I tried funning |
This PR is a split of #12583, a bit smaller so it's easier to review and less risky.
This PR keeps the Makefile and all its tasks intact. So now, both systems
(NPM and make) should work, but NPM is used everywhere (CircleCI, Dockerfile, css-hot-loader).
To keep the PR reasonably small, I've ommited any documentation changes.
cc/ @blowery @gziolo @gwwar @stephanethomas