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
What should be the next feature to focus on? #25
Comments
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. -Compression for production Holy Grail: Hot code reload. Replace module objects at runtime. |
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...) 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. |
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. |
😄 I'm currently working on a new presentation to introduce webpack: http://webpack.github.com |
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. |
Thanks for this great feedback too. I'll read/watch the stuff you linked tomorrow.
Currently only some stuff is extracted into subpackages: resolving and require for node. As every "loader" is a separate package, these are good modulized.
There is a i18n loader for webpack, but it's only working in js-land. |
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: require("./style.css");
var template = require("./template.jade");
// your js code... Than it's just a 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.
If anybody want to write a framework with webpack, supporting hot-reloading, I would support him ;) |
It's maybe possible to take care of this on module system level. I've created a separate issue for that. |
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. |
@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. |
@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 |
@sokra Sorry, I missed the update. I'll give it a shot, thank you very much! |
@plievone Localization with strings baked in: https://github.com/webpack/webpack/tree/master/examples/i18n |
+1 for supporting hot loading |
components is supported: #46 (comment) |
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... |
Toll!!! |
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 |
Sounds good :) Feel free to ask if you have any question or idea... 😄 |
old -> closed |
wiki Ideas
The text was updated successfully, but these errors were encountered: