Skip to content
This repository has been archived by the owner on Apr 9, 2022. It is now read-only.

feat: build architect for ng-packagr #444

Merged
merged 5 commits into from
Mar 19, 2018
Merged

feat: build architect for ng-packagr #444

merged 5 commits into from
Mar 19, 2018

Conversation

dherges
Copy link
Contributor

@dherges dherges commented Feb 18, 2018

Schematic for library scaffolding:

  • ng new library foo will
    • create folder lib/foo/package.json with ngPackage config
    • update tsconfig for dev experience
    • update root package.json with additional dependencies

Build architect for ng-packagr:

  • forward project param from ng-packagr

@dherges dherges requested a review from hansl as a code owner February 18, 2018 18:05
@googlebot
Copy link

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 cla/google commit status will not change from this State. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

.forProject(packageJsonPath)
.build()
.then(() => obs.complete())
.catch((e: any) => obs.error(e));
Copy link
Contributor Author

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`;
Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@dherges dherges Mar 12, 2018

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?

@dherges
Copy link
Contributor Author

dherges commented Mar 7, 2018

@dherges dherges changed the title [WIP] build architect for ng-packagr feat: build architect for ng-packagr Mar 10, 2018
}

return new Observable(obs => {
const projectNgPackagr = requireProjectModule(root, 'ng-packagr') as typeof ngPackagr;
Copy link
Contributor

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)),
Copy link
Contributor

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())
Copy link
Contributor

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 @@
{
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@hansl
Copy link
Contributor

hansl commented Mar 14, 2018

Validating David's CLA, signed on Mar 31, 2017 02:43 PDT.

@filipesilva
Copy link
Contributor

I followed up the comments in this PR in #532.

hansl pushed a commit that referenced this pull request Mar 19, 2018
hansl pushed a commit to angular/angular-cli that referenced this pull request Jun 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants