GraphQL support

[klemenoslaj]

🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• xi18n
• run
• config
• help
• version
• doc

Description

GraphQL support in Angular CLI is extremely limited or rather non existent. The big trouble for anyone trying to use Angular and GraphQL is that there is no way of pre-compile GraphQL documents. This way we end up with an extremely oversized bundles and increased script initialization.

There are solutions out there that compile GraphQL document into an AST:

• graphql-tag/loader
• babel-plugin-graphql-tag
• ts-transform-graphql-tag
• rollup-plugin-graphql

None of the solutions listed above can be used effectively if we intend to develop library containing GraphQL.
With application alone we could theoretically make it work with graphql-tag/loader. Adding library into the mix will simply not work, as ng-packagr is completely closed to any custom Rollup loaders.

Similar ng-packagr issue: ng-packagr/ng-packagr#1619

Disclamer: I know the main issue is in ng-packagr, but I wanted to see what is the overall Angular CLI take on this, since Angular CLI is "blocked" by it indirectly.

Describe the solution you'd like

If the GraphQL is big enough in Angular it could become first class citizen.
If not (probably not), we would need some convenient way of adding loaders for both applications and libraries, as covering applications alone is only half of the story.

I know ng-packagr is a complete separate project, but that is exactly the problem here. While Angular CLI is getting more open with public APIs, ng-packagr is as closed as ever.

Describe alternatives you've considered

The only alternative I can think of is a fork of ng-packagr and a custom Angular CLI packagr builder to handle this not so special case. Either that or a complete abandonment of Angular CLI.

[alan-agius4]

Hi @klemenoslaj,

Thanks for this feature request. I have discussed this with our DevRel and we agreed that adding GraphQL as a first class citizen is not in scope of the Angular CLI, as we are not opinionated about the data layer.

From an application point of view, you can use 3rd party builders to extend the CLI, such as ngx-build-plus or angular-builders.

For libraries, this is a bit more complex, because of the different module formats and only 2 of the 3 formats are being bundled using Rollup. Thus, adding any transformation at the Rollup stage is too late. Such transformations needs to happen at a TypeScript compiler level, which most likely can be achieved using the ng-packagr extension ng-cli-packagr-tasks.

[klemenoslaj]

Hi @klemenoslaj,

Thanks for this feature request. I have discussed this with our DevRel and we agreed that adding GraphQL as a first class citizen is not in scope of the Angular CLI, as we are not opinionated about the data layer.

From an application point of view, you can use 3rd party builders to extend the CLI, such as ngx-build-plus or angular-builders.

For libraries, this is a bit more complex, because of the different module formats and only 2 of the 3 formats are being bundled using Rollup. Thus, adding any transformation at the Rollup stage is too late. Such transformations needs to happen at a TypeScript compiler level, which most likely can be achieved using the ng-packagr extension ng-cli-packagr-tasks.

Hi @alan-agius4,

Thanks for the fast response.

as we are not opinionated about the data layer

That is 100% fine, and expected. The problem is, if people are getting blocked of using the technology of their choice, which is happening here. Should the issue not remain opened due to that fact alone?

From an application point of view, you can use 3rd party builders to extend the CLI

Yes, that's what I was referring to in the issue to being nicely extendable. However majority of our code is in libraries, so that doesn't help.

which most likely can be achieved using the ng-packagr extension ng-cli-packagr-tasks.

I did not know of packagr-tasks, will have a look. I am not aware of any existing TS compiler transformer (they only work on bundler level), nor am I sure if it is even possible to achieve this.

Wouldn't this be problematic due to: microsoft/TypeScript#14419?

[alan-agius4]

That is 100% fine, and expected. The problem is, if people are getting blocked of using the technology of their choice, which is happening here. Should the issue not remain opened due to that fact alone?

I don't think this is blocking, both Angular CLI and ng-packagr are extensible and you do have the possibility to extend both build system to some extend. That being said, it's important to mentioned that while extending the build system is possible, this is something which the Angular tooling team doesn't support.

While ng-packagr is not as easily extensible as the Angular CLI, this is more of an ng-packagr issue rather than the Angular CLI. I suggest you raise this problem in their issue tracker. That said, as mentioned previously there are packages like ng-cli-packagr-tasks which provided a cleaner extensibility to ng-packagr.

Yes, that's what I was referring to in the issue to being nicely extendable. However majority of our code is in libraries, so that doesn't help.

As mentioned this can possible be achieved using ng-cli-packagr-tasks, by adding a custom TS transformer or changing the NGC compilation factory. https://www.npmjs.com/package/ts-transform-graphql-tag is an example of a TS transformer for GraphQL.

Wouldn't this be problematic due to: microsoft/TypeScript#14419?

No, because transformers are already part of TS public API. So you can add a custom TS transformer.

[klemenoslaj]

That being said, it's important to mentioned that while extending the build system is possible, this is something which the Angular tooling team doesn't support.

Well this is exactly my point. The CLI is not opinionated but it doesn't provide a support for making your own opinionated decisions around tooling.
Like in the case of GraphQL, one has to go seriously out of his way to get it done and even then, there is this sentence "this is something which the Angular tooling team doesn't support" that worries me.

As far as I am concerned, this is indeed blocking. The statement is contradicting itself - not blocked, but unsupported.
Usage of unsupported APIs is not a way to go.

While ng-packagr is not as easily extensible as the Angular CLI, this is more of an ng-packagr issue rather than the Angular CLI

Yes, aware of that 👍 Anyway, wanted to address this from the perspective of CLI, since ng-packagr is being used.

[angular-automatic-lock-bot]

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.}