What should be the next feature to focus on?

[sokra]

• Store cache to file
• Chunk merging
• Loaded chunks detection
• Duplicate code detection
• Export packaged code to other module systems
• Typescript loader
• SourceMaps
• Documentation
• more?

wiki Ideas

[Phoscur]

SourceMaps, how is that different to what you have implemented already for debugging?

I think you should keep improving in direction of your original goals.
While it should stay well modularised and pluggable into grunt, it could make it unneccessairy to use grunt at all.
Add optional linting with JSHint [possibly by refactoring to get interface for code manipulation on the way] and running tests. (Watch: lint and test only changed files/folders)

-Compression for production

Holy Grail: Hot code reload. Replace module objects at runtime.

[sokra]

Thanks for your feedback :)

---

For debugging javascript SourceMaps wouldn't be a big enhancment, but for compiled languages it would be really cool. Webpack could merge a loader-generated SourceMap with the SourceMap for the chunk and you could debug coffeescript source code, when bundled with webpack. That's cool, but maybe not so important...

---

Here is a jshint-loader.

---

Compression for production

Webpack minimizes javascript with uglify-js. (I want to upgrate to uglify-js 2...)
The css-loader minimizes css source.
The url-loader can inline files as DataUrl.
Missing is image compression in the file-loader.

---

Holy Grail: Hot code reload. Replace module objects at runtime.

hmmm... really cool, but really difficult, if not even impossible.

webpack-dev-server can automatically reload the page on bundle update.

[Phoscur]

Well, if you got all that, maybe it's time to advertise a little more, get more and better documentation, and focus on stability and bugfixes.

[sokra]

😄 I'm currently working on a new presentation to introduce webpack: http://webpack.github.com
but some stuff is still missing...

[plievone]

Hi, just some thoughts.. Keeping the core simple, perhaps modularizing webpack itself to multiple packages in a nodejs/unix way so that people are more easy with using parts of it in their projects. For example, how would you develop webpack so that framework authors such as https://github.com/socketstream/socketstream-0.4 would like to use webpack instead of developing and maintaining their own asset compiler?

Also important may be to look past the code modularisation to component modularisation (code, templates, styles, images, tests, even server responders). For example see TJ Holowaychuck's blog post and Justin Tulloss' presentation on Rdio's component organization both linked to in here componentjs/component#87

I would guess that for larger projects the build time will be important for developer productivity, so getting the dependencies from parsing code vs cached config could be an important distinction. Also language versions could compose asset bundles with differences such as strings baked in place, instead of only js-land translation functions.

With simple enough build tooling more complex feats become possible. Hotloading (non-general), for example, is possible with versioning in specifically modularized codebases (rdio can update their webapp components while the sound keeps on playing), and in general I would guess people use processes or servers (by utilizing service registries etc) to get the benefits of hotloading in specific domains without too fragmented side-effects.

[sokra]

Thanks for this great feedback too. I'll read/watch the stuff you linked tomorrow.

---

Modulizing webpack

Currently only some stuff is extracted into subpackages: resolving and require for node. As every "loader" is a separate package, these are good modulized.
What features do you think should be extracted into separate packages?

---

language versions

There is a i18n loader for webpack, but it's only working in js-land.
How would you imagine to use language versions with baked strings? i. e. $(".xyz").text(I18N_XYZ_TEXT);? Syntax for accessing language dependend stuff?

[sokra]

component modularisation

I've read TJ Holowaychuk's blog post on components. Like the idea of a "component" in the way to keep small independed modules with js and resources.

You can build modules with resources really easy with webpack:
There is no complex handling of non-js resources required.

require("./style.css");
var template = require("./template.jade");
// your js code...

Than it's just a require("module").

Or you could use component/component. You just have to build a "component-loader" for webpack to consume the "component.json".

There was a (hot) discussion about component/component vs. npm. I think webpack should not take a optinion towards this. You may even mix both, if you want.

---

hot-code replacement

If anybody want to write a framework with webpack, supporting hot-reloading, I would support him ;)

[sokra]

hot-code replacement

It's maybe possible to take care of this on module system level. I've created a separate issue for that.

[sokra]

@Phoscur @plievone I changed my optinion regarding hot code replacement. It's definitly possible and awsome on module level. I already have a working node.js implementation and will create a webpack solution soon. So you'll be able to use hot code replacement in the server and the client. 😄

[miffels]

In my opinion, a mocha loader would be great. Currently I am preferring grunt over webpack for just two reasons: You do not need to write a build.js but a simple configuration file (gruntfile), and it comes with support for mocha. If building my web project from node source and still running tests etc. on node was that easy, that'd be a huge plus for webpack and a dependency less for my projects.

[sokra]

@miffels I've hacked a small example how testing with webpack could be: webpack-tests-example. If there are more people interessted I could offer it as module.

[sokra]

@miffels https://github.com/webpack/mocha-loader (Only works with webpack 0.8 beta)

I will do some tests for not included loaders with it so it can be used as example.

# webpack-dev-server@0.8.x
npm install webpack-dev-server -g
npm install mocha-loader
webpack-dev-server mocha!./tests.js
http://localhost:8080/
# It will do tests and run them again if you change a file

[miffels]

@sokra Sorry, I missed the update. I'll give it a shot, thank you very much!

[sokra]

@plievone Localization with strings baked in: https://github.com/webpack/webpack/tree/master/examples/i18n

[jcw]

+1 for supporting hot loading
+1 for supporting socketstream
+1 for supporting components

[sokra]

components is supported: #46 (comment)

[sokra]

socketstream support may be possible, but it's up to @owenb. You may write an issue there proposing it.

hot code replacement is on the roadmap...

[jcw]

Toll!!!

[owenb]

I'm keen to look into using webpack in SocketStream 0.4.

Right now I'm focussed on finishing the realtime/websocket server and client components. These will end up as separate modules, usable on their own regardless of which asset builder/module system you use in your app.

However, I still want to offer people a complete end-to-end solution and webpack may play a part in that. I have yet to fully investigate it, but already I see many good ideas.

I'll let you know when I get chance to play with it properly. Keep up the good work @sokra

[sokra]

Sounds good :)

Feel free to ask if you have any question or idea... 😄

[sokra]

old -> closed