x
)documentation issue..
Read ng eject and tell me what it is actually for. I have no idea why I need this command and what it actually does. There is an assumption I know what eject is.
https://github.com/angular/angular-cli/wiki/eject
As a developer I understand the purpose of this command.
Are you asking what is for or suggesting the docs be updated to describe better what it does ? xD
If its the former ng eject
simply means you need to do something a lot more advance or custom with webpack than what the cli provides for commands like ng build
and ng serve
.. So it generates a webpack.config.js
based on the configurations that the cli uses, so that you can then customize it further. However, that also means that you'll be able to use certain commands like ng build
and ng serve
... Let me know if that makes a bit sense. ^^
@dave11mj
Yes you are spot on, needs a bit more documentation. Thanks for clarifying the question. Let me see if I understand the purpose and propose a doc update:
If you want to use additional features of webpack that the CLI does not directly support. Use the ng eject
command to create a webpack.config.js to add the extra features that the CLI does not directly support.
All existing commands of the CLI will continue to work unaffected but the effect of the commands may be altered by your changes to the webpack.config.js file. (??)
It does give you additional webpack features but only because if you eject building and dev server become your complete responsibility, meaning you lose the support of any updates that may come to ng build
and ng serve
. If I were to describe it in a more documentation language it would be something like:
Relinquishes support for
ng build
andng serve
commands by exporting all webpack configurations into a webpack.config.js and updating package.json to reflect new dependencies. This action cannot be undone.
Another alternative would be:
Exports all webpack configurations into a webpack.config.js and updates package.json to reflect new dependencies. This action disables
ng build
,ng serve
and cannot be easily undone.
@waratah eject
makes the build configuration to be part of your app and not part of cli
itself
I am new to angular-cli and am used to tinkering with webpack configuration manually. I like all of the commands ng provides. However, if I need to modify webpack by using ng eject, can I undo this later somehow? One of my scenarios is, and maybe this is a separate issue, is that I am trying to serve a .json file from the root of the application but I am receiving a 404. I thought that maybe if I ran ng eject, I could somehow manually add this file to the build?
@PivotalAnimal you could theoretically undo ng eject
by setting "ejected" boolean on .angular-cli.json
back to false and making your package.json scripts for npm run build
and npm run start
point back to ng serve
and ng build
..
However, if you are trying to load a json you might not need to eject your application. You could place it under assets
directory, and try loading it using Angular HTTP ..
Another option to load a JSON is to add a snippet like this one on typings.d.ts
// Allows importing json files in Typescript
declare module "*.json" {
const value: any;
export default value;
}
Then you'll be able to use bring the data into your .ts
files using imports like import aboutBiographyData from './about-biography.json';
.. Note since you'd importing them directly into the file it'll increase your bundle size and not take advantage of ajax requests.
My problem with the eject
feature is that you cannot really continue development with it and build for production in the same time. You need to specify in advance which environment you are targeting, need AOT
or JIT
, etc.
It would be a nice feature to support multiple (named) ejects for development, production, etc. I mean you could issue the eject
command several times, outing into different [name].webpack.config.js
files. build
and start
could be suffixed by the name of the eject.
Update: a workaround I use is that I do eject for dev
, rename the webpack.config.js
file, revert the package.json, and do eject again for prod
with AOT
.
I'm pretty confused, I've run ng eject, and gotten the webpack config. Do I need to do another eject to get AoT support?
(Have same requirement as comment below)
I need some additional webpack config (e.g. loader or plugin) and continue development (watching without AOT) and also make prod (e.g. aot and env stuff) releases.
@dave11mj , I refer to your example about using typings.d.ts for json files.
Could you give an example how I can import a jsx or tsx file into angular4 or angular2 without the need to cli eject?
First off: I totally see no point for ng eject
at all. Simply make ng build/serve
parse a webpack configuration in the projects file tree and use that configuration. With ember-cli I can simply put my broccoli/rollup config into .ember-cli-build.js
and this should be possible with angular-cli
too.
But the eject
command has another fundamental problem: It unnecessarily couples 2 abstract features of angular-cli
ng generate
)Beside the fact that I am forced to ultimately opt out from ng build/serve
when I just want to configure something for webpack (that ng does not support yet) I am also forced to opt out from ng generate
which should have nothing to do at all with webpack. This appears as a design flaw to me. Except for I am missing something here.
If you write documentation, you have to think whether other people will understand you. So as a noob i try to read about "ng eject" and what I see? Oh, it ejects app. And what does this "eject" mean? Really generates new webpack config based on provided options? I would think it stops application which was started with ng serve or anything like that.
Hi, i am new to angular-cli and here is my scenario: I need to scan files local then generate some log files in app build stage, so I plan to write a custom webpack plugin to do this, can I use 'ng- eject' to load my custom webpack plugin ? Thanks !
Eject is a very useful command (or I would call it approach to build) which will let you do advanced builds and divorce amazing cli when needed. In my company we use ejected approach since we are running legacy AngularJS hand in hand with Angular, making it easier to build, test and deploy.
@krizic Thank you! I will have a try : )
@krizic you are talking about a project that is not under angular-cli and can thus have its webpack config changed. One of the key problems with the concept behind ng eject
is that you cannot have both (angular-cli and a modifiable webpack config) which is totally unnecessary as other tools similar to angular-cli do not have this kind of restriction at all.
@ohcibiI I am talking about project which is "under" angular-cli, once you eject webpack configuration (or several different ones e.g. prod, dev, legacy...) you are still able to use ng generators. Revert angular-cli.config to ejected:false should solve the issue you have. And yes you can have best of both worlds.
@krizic i'm aware of that hack. But this is far from intuitive. It is also not an "issue I have", its a design flaw of angular-cli. The key problem is that the webpack-config is unnecessarily coupled with the rest of angular-cli. I explained that a bit more detailed some posts above.
I am a newbie on angular-cli, so please do not throw rocks at me for what I am going to say! :smiley:
I guess the point of having webpack "coupled" with angular-cli, is that it let the Angular Team the freedom to change, if necessary, their package manager without having to worry about what impact it will have on the consumer (aka developers who just want to do "_ng new HelloWorld_").
Also, It's my understanding that performs an ng-eject and extracts the webpack config, basically let you deal with npm directly. This means that perhaps I can decide to install gulp on my project and use it to build the app by myself.
Again, I might be completely wrong here, but I don't think this is necessarily a design flow.
Using @dave11mj lead, I'm using a similar setup to expose env vars to the app, see angular-lab#environment for details.
If I've done 'ng eject' can I go back to making the cli take care of the bundling?
edit: I didn't commit my changes yet so was just able to discard my changes ;)
what does this mean I unassigned '@sumitarora' ???
@Stoffel-KT , you can undo ng eject
.
If you want to undo ng eject
, you will have to edit your .angular.cli.json file and set ejected to false:
"project": {
...
"ejected": false
}
Has anyone managed to eject and remove .angular-cli.json? It seems like the angular/cli plugin which is required for unit tests is still reading from .angular-cli.json even after an eject which doesn't seem right to me. Thoughts?
Hi guys,
I'm not sure how to revert the eject process so does this steps are logical and help me what I like to do.
I like to know if this is possible. Does the last step when replace old package.json will know how to use the new version of webpack when I have added the new plugin?
This issue is now obsolete due to changes in the recent releases. Eject is no longer supported.
Which commit closes this?
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._
Most helpful comment
First off: I totally see no point for
ng eject
at all. Simply makeng build/serve
parse a webpack configuration in the projects file tree and use that configuration. With ember-cli I can simply put my broccoli/rollup config into.ember-cli-build.js
and this should be possible withangular-cli
too.But the
eject
command has another fundamental problem: It unnecessarily couples 2 abstract features ofangular-cli
ng generate
)Beside the fact that I am forced to ultimately opt out from
ng build/serve
when I just want to configure something for webpack (that ng does not support yet) I am also forced to opt out fromng generate
which should have nothing to do at all with webpack. This appears as a design flaw to me. Except for I am missing something here.