Skip to content

build: make packaging more flexible #6143

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

Merged

Conversation

devversion
Copy link
Member

@devversion devversion commented Jul 29, 2017

  • Makes the packaging more flexible by no longer including checks that are specific to the Angular Material project (e.g material => lib mapping)
  • Updates the code to be more readable by making the packaging more object orientated (TS compilation helpers shouldn't be part of the gulp task generation)
  • Avoids repeating the path joining ~100x times by just passing the build package instance around.

@devversion devversion requested a review from jelbourn as a code owner July 29, 2017 13:18
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Jul 29, 2017
* Makes the packaging more flexible by no longer including checks that are specific to the Angular Material project (e.g `material` => `lib` mapping)
* Updates the code to be more readable by making the packaging more object orientated (TS compilation helpers shouldn't be part of the gulp task generation)
@devversion devversion force-pushed the build/more-generic-packaging branch from e3b5ba9 to a3509a3 Compare July 29, 2017 14:38
export const examplesPackage = new BuildPackage('material-examples', [materialPackage, cdkPackage]);

// To avoid refactoring of the project the material package will map to the source path `lib/`.
materialPackage.packageRoot = join(buildConfig.packagesDir, 'lib');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you you think of making the second constructor arg a config / options object so that it looks like

export const materialPackage = new BuildPackage('material', {
  deps: [cdkPackage],
  root: join(buildConfig.packagesDir, 'lib'),
});

?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to avoid something like that. It's really a special case that we want to overwrite the packageRoot here and it should not really be done through the build package.

Normally the build config is responsible for changing such things, but since this is really a special case I think this would be fine (it's just a single line; which is pretty clear IMO)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel strongly either way

Copy link
Member

@jelbourn jelbourn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jelbourn jelbourn added pr: lgtm action: merge The PR is ready for merge by the caretaker and removed pr: needs review labels Jul 31, 2017
@tinayuangao tinayuangao merged commit 056d3b2 into angular:master Aug 1, 2017
@devversion devversion deleted the build/more-generic-packaging branch November 11, 2017 10:22
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants