Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Jaybell/make buildable schematic #8916
Jaybell/make buildable schematic #8916
Changes from all commits
f139a12
18ca01a
2ca9903
592932e
824946b
dccf994
cf57394
8bd2bcb
a529847
c729b0a
bdf76d8
b50b692
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 check makes sense if we keep going with only single-project command. So this isn't necessarily a change request, but rather a discussion point. Should we change this generator to take --all similar to how it works with the convert-to-nx-project generator? Should it be able to take a list of projects instead of only 1?
Since buildable libs can only depend on other buildable libs, I feel like the most common DX will be converting all libs that are in an apps dependency tree to buildable at the same time.
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 would say yes we do want to be able to support that (and it's something I thought about while building this). Just a couple of things to consider:
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.
Ideally, I think this would be built into each package:
nx g @nrwl/js:library lib1 --buildable
would be equivalent to say likenx g @nrwl/js:library lib1 && nx g @nrwl/js:add-build lib1
@nrwl/jest:jest-project
adds atest
target onto an existing project.@nrwl/react:add-build
would inherit@nrwl/web:add-build
We have 4 executors (3 in this PR + angular) so I think this would probably wind up being 4 executors?
We used this kind of strategy for
convert-to-eslint
.What do you all think?
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.
Yeah it might make more sense to have this split into each package. it would help keep like-minded code together, especially if we ever need to change how we create buildable libs and their config (e.g. angular might have to have some work done to the buildable lib implementation).
If the functionality to generate a buildable lib was extracted into a generator
add-build
that generator could just be reused in the library generator when--buildable
is passed, as you suggested.I like it, I think that makes more sense.
We could still have a generator in workspace package that will then call the underlying generators.
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 we have these split into their respective packages, and have the root level 'add-buildable --all' option, how would it know run the generators? Should a generator in @nrwl/workspace rely on generators in other verticals? I wouldn't think so, but maybe dynamic imports would be a "good enough" way of doing them without adding deps to each plugin that supports buildable libs.
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 was thinking more along the lines of
execSync(nx g ${packageName}:add-buildable)