-
Notifications
You must be signed in to change notification settings - Fork 28
Conversation
Codecov Report
@@ Coverage Diff @@
## master #219 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 56 58 +2
Lines 1305 1340 +35
Branches 195 197 +2
=====================================
+ Hits 1305 1340 +35
Continue to review full report at Codecov.
|
@@ -66,10 +66,10 @@ function getFileContents(filePath) { | |||
switch (path.extname(filePath)) { | |||
case '.scss': | |||
contents = compileSass(filePath); | |||
break; | |||
break; |
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's unclear how this got in to start with, but the linter complained to be about the spacing.
Hey @Blackbaud-SteveBrush and @Blackbaud-PaulCrowder, this one is ready for review. The factoring out of Let me know if you have any questions or want to talk through any of it. |
@Blackbaud-BobbyEarl: Launching on localhost works great!
However, when using |
One last comment, and this is just a matter of preference: it might be nice to have a default value, so that consumers could type |
Thanks for the feedback @Blackbaud-SteveBrush. Based on it, I've implemented the following changes:
These together mean you can run some pretty neat commands, for example to launch the local url in safari... |
@@ -91,6 +85,7 @@ function spawnProtractor(chunks, port, skyPagesConfig) { | |||
protractorPath, | |||
[ | |||
getProtractorConfigPath(), | |||
`--disableChecks`, |
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.
FYI, adding this check to solve the "unknown arguments" warning (soon to be error) that's shown. https://github.com/angular/protractor/blob/master/CHANGELOG.md#features-3
cli/build.js
Outdated
} else if (argv.serve) { | ||
buildServe(argv, skyPagesConfig, webpack, isAot); | ||
} else { | ||
return buildPromise(argv, skyPagesConfig, webpack, isAot); |
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.
Curious why we're returning the promise for buildPromise
, but not for buildServe
? Would it be appropriate to also catch any server errors?
function buildServe(argv, skyPagesConfig, webpack, isAot) {
return server.start(skyPagesConfigUtil.getAppBase(skyPagesConfig))
.then(port => {
argv.assets = argv.assets || `https://localhost:${port}`;
return buildPromise(argv, skyPagesConfig, webpack, isAot);
})
.then(stats => browser(argv, skyPagesConfig, stats, port));
}
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 also makes me wonder if we were ever handling failures during the build step. Aside from linting errors, I don't see a process.exit
for build issues. Is that by design?
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.
If skyux build
fails outside of linting, the ProcessExitCode plugin calls process.exit
.
I was really only concerned with returning a promise from buildPromise
knowing that cli/e2e.js
imports build
, which wouldn't be passing the serve
command. It definitely makes sense to make the signature the same (always returning a promise) regardless of the arguments.
tl;dr I'm going to push an update to always have build
return a promise, but process.exit
is handled in the webpack plugin.
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.
Gotcha. That makes sense!
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.
Wonder if I should still reject the promise, even if it's linting that fails? I'm thinking so, such that the command always returns a promise regardless of what actually failed.
@@ -218,7 +177,7 @@ function e2e(argv, skyPagesConfig, webpack) { | |||
return killServers(0); | |||
} | |||
|
|||
spawnServer() | |||
server.start() |
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.
So much cleaner; love it.
} else { | ||
|
||
const url = 'https://github.com/blackbaud/skyux-template'; | ||
const branch = 'master'; |
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 pointed the branch to builder-dev
(a protected branch) so that we could adjust the template as needed without affecting what consumers are cloning when typing skyux new
. Unsure how you feel about this.
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.
(This is also helpful for when we have various versions of SKY UX that need to be tested during a Travis build.)
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.
Changing this wasn't intentional... chalking it up to me being ignorant when resolving merge conflicts.
Learning about it though, I'm torn. It seems nice for development for new features in builder that may require a change to the template. On the other hand, running builder's e2e tests is used to test that skyux new
runs as intended for consumers, in which case they'd be using the master
branch.
I'll change it back to builder-dev
for the sake of this PR and we can talk more about it later.
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 is non-blocking feedback (because the feature works fantastically), but the build promise chain could be simplified a bit since all of the various methods return promises already (removed all new Promise
, resolve
, reject
, etc.):
// ...
function buildServe(argv, skyPagesConfig, webpack, isAot) {
return server.start(skyPagesConfigUtil.getAppBase(skyPagesConfig))
.then(port => {
argv.assets = argv.assets || `https://localhost:${port}`;
return buildCompiler(argv, skyPagesConfig, webpack, isAot)
.then(stats => browser(argv, skyPagesConfig, stats, port));
});
}
function buildCompiler(argv, skyPagesConfig, webpack, isAot) {
// ...
return runCompiler(webpack, config, isAot)
.then(stats => {
if (isAot) {
cleanupAot();
}
return stats;
});
}
function build(argv, skyPagesConfig, webpack) {
// ...
const name = argv.serve ? buildServe : buildCompiler;
return name(argv, skyPagesConfig, webpack, isAot);
}
// ...
Any feedback before this gets merged in @Blackbaud-PaulCrowder? |
This modification exposes the
-l
or--launch
flag toskyux build
, which will acceptlocal
andhost
as values. Essentially, it easily allows a "built" SPA to be served.blackbaud/skyux2#562
blackbaud/skyux2#890