-
Notifications
You must be signed in to change notification settings - Fork 156
Conversation
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the |
.forProject(packageJsonPath) | ||
.build() | ||
.then(() => obs.complete()) | ||
.catch((e: any) => obs.error(e)); |
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.
At the moment, the only way is passing a file path in either ngPackagr.forProject()
or in the build()
command
if (!json.scripts) { | ||
json.scripts = {}; | ||
} | ||
json.scripts[`libs:${name}:build`] = `ng-packagr -p ${sourceDir}/package.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.
Should the script invoke ng-packagr directly or run through the build architect?
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 the ng
command to build is the one that should be called here, which in turn would call architect with the workspace setup.
Although I do wonder if we should be adding the individual scripts at all when adding a new project/lib via schematic.
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 just hook past your CLI? You should probably expose a JavaScript API that we can use directly.
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.
Yes, should the schematic create the workspace setup for Builder/Runner/Architect? What is the command users will execute then?
|
} | ||
|
||
return new Observable(obs => { | ||
const projectNgPackagr = requireProjectModule(root, 'ng-packagr') as typeof ngPackagr; |
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'm actually not sure either NgPackager, nor TsLint (where this setup code came from) should be loaded as project dependencies.
I think it should either be a peer dependency, or a direct dependency. Both of those approaches have pros and cons, but in either case I don't think we should try to short-circuit it by requiring the project module instead of importing directly.
In the case of NgPackagr, you already have it as a direct dependency so I think we can import it directly.
architect.loadWorkspaceFromJson(getWorkspace()).pipe( | ||
concatMap((architect) => architect.run(architect.getTarget())), | ||
toArray(), | ||
tap(events => expect(events.length).toBe(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.
At the when I linked you the TSlint example the tests there were a bit anemic. Since then I added more, and more involved ones.
I think here you should check the build event success, and also check if the output is what you expected. An example of a test that does that is https://github.com/angular/devkit/blob/master/packages/angular_devkit/build_webpack/test/tslint/works_spec_large.ts#L54-L67.
projectNgPackagr.ngPackagr() | ||
.forProject(packageJsonPath) | ||
.build() | ||
.then(() => obs.complete()) |
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.
Overall we're trying to go for a model where builders always emit events. This wasn't the case before when you started working on it but since then we revised that because otherwise it was harder to test and reason about it.
The general idea is:
- whenever a builder finished a build, it will emit
{success: true}
if it succeeded or{success: false}
if it did not - when a builder is done, it will complete. Builders on watch mode would emit multiple times and not complete, whereas single run builders should emit once and complete.
- when there is an error, the builder should
obs.error
. Note that this is different from a failed build though, which emits a{success: false}
and no error. I think the usage of error you have here is the right one.
@@ -0,0 +1,60 @@ | |||
{ |
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 know these files are needed for now but we need to review the final file set for adding a library to an existing project before wrapping up.
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.
Should I strip the test to be a minimal sample? WOuld only be a package.json
, a few *.ts
/*.html
/*.css
files and then I'll verify the dist
folder is created.
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.
Yes that would be preferable, that way the tests only include what they need and it is easier to keep them updated.
Validating David's CLA, signed on Mar 31, 2017 02:43 PDT. |
I followed up the comments in this PR in #532. |
Followup to comments in angular/devkit#444
Schematic for library scaffolding:
ng new library foo
willlib/foo/package.json
with ngPackage configBuild architect for ng-packagr: