This repository has been archived by the owner. It is now read-only.

docs(cb-webpack): add cookbook about webpack #1094

Merged
merged 1 commit into from May 13, 2016

Conversation

Projects
None yet
4 participants
@Foxandxss
Member

Foxandxss commented Apr 15, 2016

Here is my cookbook. A bit longer than a normal cookbook but there are a lot of people asking for webpack information and I tested this configuration quite a bit so it is a good starting point for projects.

There is a problem tho, I cannot run the e2e tests with the current tooling.

All the guides / tutorials / cookbooks shares the same node_modules, tsconfig, package.json... and this cookbook doesn't share them. So we need a way to install this cookbook node_modules too.

On the other hand, protractor expects two task to be run http-server:e2e and tsc. That is easily fixable by creating those task to run "webpack stuff".

Big problem is that protractor will simply ignore my cookbook unless I create the example-config.json. If I create that file, protractor will bring all the shared stuff over my project. Overriding my package.json, typings, tsconfig, etc. No bueno.

So all the tooling regarding e2e is a big coupled together and my project is the first one with special needs and probably not the last one.

What should we do for projects that needs their own dependencies and files?

@googlebot googlebot added the CLA: yes label Apr 15, 2016

@wardbell

This comment has been minimized.

Contributor

wardbell commented May 10, 2016

You should be able to extend the node_modules in the _examples/package.json to include the ones you need that aren't there already ... unless you're saying you need alternatives to the ones we require now. That would be a problem.

Do you need your own local package.json? Why?

It shouldn't be a problem to have your own tsconfig with a different name and write a bash/command/gulp scripts to invoke them (I'd use gulp). Then you can ignore our standard npm scripts. Do the same with your own protractor.conf and reference it.

I'd be happy to define an additional scheme for running your e2e-tests as part of the larger run.

Let's work this out apart from this issue/PR.

Meanwhile ... want to get this in the documentation as soon as we can.

@Foxandxss

This comment has been minimized.

Member

Foxandxss commented May 10, 2016

With the new tsconfig doing commonjs, I can use the same.

Local package.json is because two things:

a) I need a lot of webpack related libraries (css-loader, extract-text-webpack-plugin, html-loader, html-webpack-plugin, jasmine-core, null-loader, phantomjs-prebuilt, raw-loader, style-loader, ts-loader, webpack, webpack-dev-server, webpack-merge). It is like 15 new libraries to add to our common package.json

b) the scripts are actually different (this is more problematic). Our package.json runs tsc and lite-server, I need to run webpack server.

So I really need my own package.json for webpack. The rest are the exact same thing and doesn't need replacement, well, except the node_modules that comes with the package.json.

Oh lies, needs an extra typing too but that is way less problematic.

For the time being, I am updating this to new world.

PS: Yeah, I could ignore npm scripts and run everything differently for protractor sake and teach something different for the cookbook.

@wardbell

This comment has been minimized.

Contributor

wardbell commented May 10, 2016

You do not need your own package.json

  • I don't care if our _examples/package.json loads more node_module. Add more. That's ok. It's a one-time hit
  • you can create additional webpack scripts for everything if you don't want to use gulp. I don't care. Call them tsc:webpack and start:webpack or whatever. Just make sure they don't conflict with the ones we use elsewhere.
@Foxandxss

This comment has been minimized.

Member

Foxandxss commented May 10, 2016

Your solution is indeed the simpler way to make this roll, but I am afraid of ending with a package.json big enough if we start adding more build tools cookbooks. Also I remember @teropa needing a custom solution too.

Let me throw an idea here:

The way our e2e works is by looking for a example-config.json in a guide and if found, will add the boilerplate to it and run 1-2 npm scripts to launch a server and test.

What if we add a custom-config.json file as a "flag" so when protractor reads it, instead of moving boilerplate to it, will run npm install in it and then running those npm scripts that will launch a server (those custom guides will have a way to launch a server that protractor can work with) and be tested.

Downsides are having lot of node_modules (one for each custom guide) but as a upside we can have more custom guides without interfering with your general tooling.

@wardbell

This comment has been minimized.

Contributor

wardbell commented May 10, 2016

Changes:

Biggest thing is that the application folder structure must follow the CLI standard which is src/app/... Please conform to the output of the CLI. We are migrating everything to that.

The next big thing is conversion to RC1. That changes a lot ... including the shims (no angular2-polyfills; add the zones and reflect-metadata shims)

Your example should begin with the output of the CLI QuickStart. Basically the minimum out of the box from the CLI.

Adjust your npm scripts per the above. I know you tell them npm start. You will create a package.webpack.json that looks the way they should have it (just as we do for package.1.json in QuickStart). But that won't be the one we actually use for developing and running the samples locally within _examples. We'll have npm run start:webpack and such.

Same game with karma.webpack.conf.js ... if we need one that is different. I don't think we will for the version.

Will the webpack version support TDD? What happens when I change an app file? What's the watching story?

We need link(s) to webpack resources where the reader can learn more.

Standing by to move this along! Thanks, Jesus!

@googlebot

This comment has been minimized.

googlebot commented May 10, 2016

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

1 similar comment
@googlebot

This comment has been minimized.

googlebot commented May 10, 2016

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

@googlebot googlebot added CLA: no and removed CLA: yes labels May 10, 2016

@googlebot

This comment has been minimized.

googlebot commented May 10, 2016

CLAs look good, thanks!

1 similar comment
@googlebot

This comment has been minimized.

googlebot commented May 10, 2016

CLAs look good, thanks!

@googlebot googlebot added CLA: yes and removed CLA: no labels May 10, 2016

@googlebot

This comment has been minimized.

googlebot commented May 12, 2016

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

1 similar comment
@googlebot

This comment has been minimized.

googlebot commented May 12, 2016

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

@googlebot googlebot added CLA: no and removed CLA: yes labels May 12, 2016

@wardbell

This comment has been minimized.

Contributor

wardbell commented May 12, 2016

@googlebot chill out. All authors are ok with these commits

@wardbell

This comment has been minimized.

Contributor

wardbell commented May 12, 2016

The cb-webpack/ts/karma.webpack.conf.js is missing from source control so we're getting a BAD FILE for the karma.conf.js file. There is a ts/config/karma.conf.js; is that what we should be showing.

The ts/config/karma-test-shim.js is also missing and producing a BAD FILE message.

Please make these corrections and review my changes so we can publish this ASAP.

P.S. What is the workflow for development and testing? Is there the equivalent of browser sync? Am I running development and karma at the same time. Do they refresh as I make code/spec changes? Is that fast?

@wardbell

This comment has been minimized.

Contributor

wardbell commented May 12, 2016

While you're there, please fix "Configurating Webpack" -> "Configuring Webpack" in the ToC.

@Foxandxss

This comment has been minimized.

Member

Foxandxss commented May 12, 2016

Missing files added. I added the karma.conf.js (in reality karma.webpack.conf.js). It is needed because that one redirects to the one at config/.

test-shim added too (I changed the name to match the CLI and that name is globally ignored).

For workflow, you npm start (`npm run start:webpack for us in the tooling). That will update the page every time we change something.

For testing you can do npm test (npm run test:webpack for us) and that will listen for any changes and re-run tests.

Changes are fast enough :)

@Foxandxss

This comment has been minimized.

Member

Foxandxss commented May 12, 2016

I am going to make a final sweep to verify that everything is in order.

@wardbell

This comment has been minimized.

Contributor

wardbell commented May 12, 2016

Sorry ... one more biggish thing. This is really a guide chapter ... far more than it is a cookbook.

I love it and I am happy that it is.

But that means moving it to Guide and (harder) stripping the cb- prefix everywhere.

Please do that and we'll drop it in. Thanks!

@Foxandxss

This comment has been minimized.

Member

Foxandxss commented May 12, 2016

No one will ever know this was a cookbook once. Job done.

@Foxandxss

This comment has been minimized.

Member

Foxandxss commented May 12, 2016

Let me double check, perhaps some files are missing.

@googlebot

This comment has been minimized.

googlebot commented May 13, 2016

CLAs look good, thanks!

@googlebot

This comment has been minimized.

googlebot commented May 13, 2016

CLAs look good, thanks!

@googlebot googlebot added CLA: yes and removed CLA: no labels May 13, 2016

@wardbell wardbell merged commit 96238bb into angular:master May 13, 2016

1 check passed

cla/google All necessary CLAs are signed

@wardbell wardbell deleted the IdeaBlade:cb/webpack branch May 13, 2016

@TheLarkInn

This comment has been minimized.

Member

TheLarkInn commented May 13, 2016

Mind if I come back around with some opinionated and collaborative suggestions? I really want to see webpack be as simple as possible for people to embrace.

@Foxandxss

This comment has been minimized.

Member

Foxandxss commented May 13, 2016

Of course not. You know where you can find me.

@TheLarkInn

This comment has been minimized.

Member

TheLarkInn commented May 13, 2016

K

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.