Skip to content
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

Write bundle to disk #62

Closed
KyleAMathews opened this issue Sep 24, 2014 · 81 comments
Closed

Write bundle to disk #62

KyleAMathews opened this issue Sep 24, 2014 · 81 comments

Comments

@KyleAMathews
Copy link

@KyleAMathews KyleAMathews commented Sep 24, 2014

I'm developing an app that has several entry points — one of which needs a custom html file that I'm generating using a View in my hapi.js server.

Is there a way I can configure the dev-server to write the generated js files to disk? Right now I either have to have another webpack watcher to compile files or stop and manually compile the files when I make a change to that particular part of the code.

@iirvine

This comment has been minimized.

Copy link

@iirvine iirvine commented Oct 12, 2014

I'd like to see an option like this as well. At least from my initial webpack experiments, it seems that being able to write the dev server output to disk would make working in parallel with another server much simpler. Right now I have a fairly complicated work-around of loading static assets from the dev server based on an environment variable, which works okay for a single bundle but breaks code-splitting.

@sokra

This comment has been minimized.

Copy link
Member

@sokra sokra commented Oct 13, 2014

The webpack-dev-server doesn't write files to disk. You can use webpack --watch which writes files to disk. But why would you need to access the generated assets? This shouldn't be required.
When using with an existing server you should thread the webpack assets as blackbox that exists at a special URL.

@iirvine

This comment has been minimized.

Copy link

@iirvine iirvine commented Oct 13, 2014

Right, it makes a bit more sense now that I've worked with webpack a little more - it just necessitates my server having some notion of that blackbox in development, rather than always just serving assets from disk.

@devel-pa

This comment has been minimized.

Copy link

@devel-pa devel-pa commented Oct 29, 2014

yesterday, a bad day, so I'll delete the things I wrote here.
Webpack works with WebStorm very well.

You have to set in remote urls the mapping of your sources starting from "webpack:///."

PS: and it worked only for a minute. now, back to nothing

@sompylasar

This comment has been minimized.

Copy link

@sompylasar sompylasar commented Nov 29, 2014

But why would you need to access the generated assets? This shouldn't be required.

While debugging the build process (webpack build configuration, webpack loaders configuration, project file structure), you could have to look into the generated files to understand what has gone wrong.

BTW, webpack-dev-server does not reload webpack config file when it changes either. So we have to restart the server. Luckily, the browser-side waits for it and catches up (thanks for that!).

@max-mykhailenko

This comment has been minimized.

Copy link

@max-mykhailenko max-mykhailenko commented Jan 5, 2015

+1

@sokra

This comment has been minimized.

Copy link
Member

@sokra sokra commented Jan 5, 2015

Writing to disk is not an option for the webpack-dev-server. Instead you can use webpack --watch which does the same but writes files to disk + a static fileserver.

@sokra sokra closed this Jan 5, 2015
@diurnalist

This comment has been minimized.

Copy link
Contributor

@diurnalist diurnalist commented Jan 28, 2015

@sompylasar this is a very late reply, but you can examine the generated assets if you visit your dev server under the /webpack-dev-server path. I.e. if you're running it on 9000, http://localhost:9000/webpack-dev-server.

@sompylasar

This comment has been minimized.

Copy link

@sompylasar sompylasar commented Jan 28, 2015

@diurnalist Sure, I know. This is how I do debugging in the browser. But I wanted to have the files in my text editor rather than in the browser's developer tools.

@KyleAMathews

This comment has been minimized.

Copy link
Author

@KyleAMathews KyleAMathews commented Jan 28, 2015

@sokra but that means you can't do hot-reloads...

@diurnalist

This comment has been minimized.

Copy link
Contributor

@diurnalist diurnalist commented Jan 29, 2015

@KyleAMathews how so? Nothing about hot reloads requires the assets be written to disk. I'm using it in a project right now without issue.

@KyleAMathews

This comment has been minimized.

Copy link
Author

@KyleAMathews KyleAMathews commented Jan 29, 2015

@diurnalist sorry wasn't clear — I want assets written to the disk. I was the one who originally created this issue ;-)

Right now I have to run both webpack-dev-server and webpack -w.

@diurnalist

This comment has been minimized.

Copy link
Contributor

@diurnalist diurnalist commented Feb 1, 2015

@KyleAMathews hmm, I'm still trying to understand why you need to run two webpack compilations. It seems irrelevant how the bundle is served. The only thing I can think is that somehow you need to do additional processing outside of webpack land on one of your output files? Feel free to send me an email (listed on my profile) - I've had to deal with a few weird things when integrating webpack into a big project, maybe my experience can be of use.

@max-mykhailenko

This comment has been minimized.

Copy link

@max-mykhailenko max-mykhailenko commented Feb 1, 2015

@KyleAMathews you can try setup git hook and run webpack on commit, pull etc.

@KyleAMathews

This comment has been minimized.

Copy link
Author

@KyleAMathews KyleAMathews commented Feb 2, 2015

@diurnalist I have two entry points, one of which I want served by webpack-dev-server for hot reloading (an admin page) and the other entry point I need compiled to disk so it can be loaded as part of a server generated React page.

@max-mykhailenko I need to see the results of my changes before committing ;-)

@sokra

This comment has been minimized.

Copy link
Member

@sokra sokra commented Feb 4, 2015

I have two entry points

You should have two configurations, because the target option differs: web and node.

@KyleAMathews

This comment has been minimized.

Copy link
Author

@KyleAMathews KyleAMathews commented Feb 5, 2015

@sokra I was a bit unclear — the target for both entry points is the web — React is used to generate the initial html page that's sent but I still need the compiled js to animate the react app in the browser.

@diurnalist

This comment has been minimized.

Copy link
Contributor

@diurnalist diurnalist commented Feb 6, 2015

@KyleAMathews so, just to be clear (again, happy to discuss via email, these GH comment reply flows get a bit ridic after a certain point...) - does your generated HTML file need to include the script inlined? Or is it fine to include it as an external link? Obviously if the latter is true, you can simply link your script in:

<script src="http://localhost:9090/js/your-react-bundle.js"></script>

You'd just need to be able to change the host for when you deploy the app to a remote server, obviously.

If you need to actually inline your script... that's a different issue. But, I'd ask: why would you need to do that? For what it's worth, it's possible. I'm currently doing it to bootstrap some page-specific JSON into my app when it starts. The tricky part here is you need to understand what IDs webpack has assigned your modules. To do that, you need to parse the stats object webpack returns when a compilation completes. I have some code I could open-source that helps with this.

Basically, I have some script template that looks something like this:

webpackJsonp([], {
  0: function (module, exports, require) {
    var App = require(__APPLICATION_MODULE_ID__);
    App.start(__BOOTSTRAP_DATA__);
  }
});

And then when I'm generating my HTML page, I just read that template and replace the tokens with the webpack module id for the App module and the JSON string of bootstrap data. This works essentially by injecting a dummy webpack chunk on to the page that has no dependencies. You would need to ensure that you have loaded the main webpack library on the page before doing this, or else the webpackJsonp function will not exist yet.

@QuantumInformation

This comment has been minimized.

Copy link

@QuantumInformation QuantumInformation commented Apr 14, 2015

I basically want the server auto refreshing when I make changes in the code, similar to how the ember-cli works.

@choonkending choonkending mentioned this issue Jul 18, 2015
4 of 4 tasks complete
hxgdzyuyi added a commit to komic-awesome/komic that referenced this issue Jul 23, 2015
webpack 从 node_modules 和 bower_components 中读取模块。
调试请使用 `grunt webpack-dev-server`, 访问 8000 端口

- webpack-dev-server 编译生成的文件并不写入硬盘
webpack/webpack-dev-server#62
- 配置教程
http://kevinold.com/2015/02/04/configure-webpack-dev-server-and-react-hot-loader-with-ruby-on-rails.html
hxgdzyuyi added a commit to komic-awesome/komic that referenced this issue Jul 23, 2015
webpack 从 node_modules 和 bower_components 中读取模块。
调试请使用 `grunt webpack-dev-server`, 访问 8000 端口

- webpack-dev-server 编译生成的文件并不写入硬盘
webpack/webpack-dev-server#62
- 配置教程
http://kevinold.com/2015/02/04/configure-webpack-dev-server-and-react-hot-loader-with-ruby-on-rails.html
@nickpresta

This comment has been minimized.

Copy link

@nickpresta nickpresta commented Sep 3, 2015

I've tried to follow allow this thread and the linked threads, but I'm still unsure of my current options.

It is possible to run Webpack Dev Server in "hot reload" mode (to support React Hot Loader, etc) while still writing the files to disk?

@JorritPosthuma

This comment has been minimized.

Copy link

@JorritPosthuma JorritPosthuma commented Sep 15, 2015

I'd like to add an argument for adding this option 😊. When using electron, in certain cases, you are only allowed to use files from a file: path: https://github.com/atom/electron/blob/master/atom/renderer/lib/web-view/web-view-attributes.coffee#L201

@nickpresta As far as I know, not right now. You have to run a separate webpack -w.

@thelinuxlich

This comment has been minimized.

Copy link

@thelinuxlich thelinuxlich commented Sep 25, 2015

+1 for dev server writing to disk!

@sheerun

This comment has been minimized.

Copy link

@sheerun sheerun commented Oct 8, 2015

We also needed it for node's native modules (.node). They can't be loaded from web server.

@mrberggg

This comment has been minimized.

Copy link

@mrberggg mrberggg commented Oct 20, 2015

+1 for writing to disk. Just adds confusion when starting out.

@gajus

This comment has been minimized.

Copy link
Member

@gajus gajus commented Mar 13, 2017

It doesn't seem right that I need a plugin for this.

Whats the problem with using a plugin?

@simon-paris

This comment has been minimized.

Copy link

@simon-paris simon-paris commented Mar 13, 2017

Whats the problem with using a plugin?

I feel like this should be a built in behavior.

@gajus

This comment has been minimized.

Copy link
Member

@gajus gajus commented Mar 13, 2017

The core features are dictated by the mainstream use. This isn't a mainstream use case. Plugins are to support alternative use cases.

@ashish-chopra

This comment has been minimized.

Copy link

@ashish-chopra ashish-chopra commented Mar 17, 2017

Thanks @gajus. After a long search related to emit usecase i landed upto this thread and found your plugin a Savior. THanks. +1 for your plugin.

@cchamberlain

This comment has been minimized.

Copy link

@cchamberlain cchamberlain commented Apr 19, 2017

I am writing a C# => TypeScript transpiler plugin. TypeScript editors / type checkers require hard files on disk. Currently detecting if I'm running in watch and using fs.writeFile to emit assets, otherwise I use the assets object. It would be nice to be able to route assets to avoid less differences in dev / prod code paths.

@SteveGBanton

This comment has been minimized.

Copy link

@SteveGBanton SteveGBanton commented Jun 3, 2017

@anuja8275 @simon-paris @ashish-chopra What if you just use:

"start": "./node_modules/.bin/webpack-dev-server && ./node_modules/.bin/webpack"

in your package.json? Dev server runs first and you make your edits. When done you ctrl-c to close the terminal process and webpack will automatically start to create the file system bundle.

@Kos

This comment has been minimized.

Copy link

@Kos Kos commented Jun 29, 2017

@SteveGBanton I don't think that would provide good usability - most users expect Ctrl+C to be instantenous and a webpack run can easily take half a minute.

@feusebio

This comment has been minimized.

Copy link

@feusebio feusebio commented Jun 30, 2017

I had some problems to get file bundled in dir that i want, the problem was because i run webpack in Windows, and i had to change the slash in paths.
Ex: context: __dirname + '/resources/assets/js', to context: __dirname + '\\resources\\assets\\js',

@SteveGBanton

This comment has been minimized.

Copy link

@SteveGBanton SteveGBanton commented Jul 2, 2017

@Kos You're right, might be a bit awkward in some cases. This also works for me:

"scripts": {
"start": "./node_modules/.bin/webpack-dev-server",
"start-disk": "./node_modules/.bin/webpack --watch"
}

Run 'npm start' first, then 'npm run start-disk' in a separate terminal window. You can develop with webpack-dev-server and bundle is automatically written to disk at the same time through webpack --watch... Might need to delete your bundle file to start.

@asumaran

This comment has been minimized.

Copy link

@asumaran asumaran commented Jul 26, 2017

I've spent 20 minutes reloading and deleting node_modules and reinstalling everything just to find out webpack-dev-server doesn't write to disk. Usually I want to check what in the bundle is changing or sometimes I want to check how the code is generated (for technical purposes) That's why I think it's useful to have an option to write the generated files to disk so I can check them in my own editor to inspect changes.

@herzinger

This comment has been minimized.

Copy link

@herzinger herzinger commented Sep 3, 2017

@gajus great plugin, thanks!

That being said, I'm also of the opinion it should be integrated in the core project, as an optional flag. I don't even have a complicated user case, I just like to see what's being outputted right there in my ide whenever I want to. I don't believe I'm alone in that.

@atrauzzi

This comment has been minimized.

Copy link

@atrauzzi atrauzzi commented Sep 7, 2017

Working on an electron app. Would like to be able to serve the initial main from the filesystem, but have subsequent loads work via the server.

@veetil09

This comment has been minimized.

Copy link

@veetil09 veetil09 commented Sep 25, 2017

@gajus Hey, thanks for the plugin. You may want to surround the fs.writeFileSync(relativeOutputPath.split('?')[0], assetSource); in a try-catch since it can throw an exception.

@gajus

This comment has been minimized.

Copy link
Member

@gajus gajus commented Sep 26, 2017

@gajus Hey, thanks for the plugin. You may want to surround the fs.writeFileSync(relativeOutputPath.split('?')[0], assetSource); in a try-catch since it can throw an exception.

PR welcome.

@veetil09

This comment has been minimized.

Copy link

@veetil09 veetil09 commented Sep 26, 2017

@valorloff

This comment has been minimized.

Copy link

@valorloff valorloff commented Dec 17, 2017

This feature is highly needed for HMR universal apps, when need re-bundle server and send changed client.bundle to the client

@heisian

This comment has been minimized.

Copy link

@heisian heisian commented Jan 22, 2018

@everyone I see at least two viable solutions provided here in this thread so let's make a couple things clear before we keep asking to add more stuff:

  1. ANY addition to webpack functionality is by nature a plugin. So if you think writing to disk should be an option and not a plugin, guess what, any way you slice it it will be a (internal) plugin.
  2. @gajus 's solution which I'm about to try out! https://github.com/gajus/write-file-webpack-plugin
  3. @chikara-chan 's super easy plugin which I will try first.

Now, the reason I want write-to-disk is b/c I need to be able to make server-side changes without having to re-compile the client from scratch when the server restarts. I am aware of chokidar watching for require.cache deletion, but it didn't work at all in my case.

I've separated out the processes, but the only way I see the forked server process being able to get the references to the webpack assets in-memory is via node's IPC channels (someone correct me if I'm wrong!).

While probably the best/correct solution, I don't really want to mess with it when serving static files on disk is trivial in comparison. Being able to use HMR w/ that absolute path on-disk would be so easy I could eat an everything bagel with morning coffee, take a dump, and read the paper while still filling my daily quota of code lines. Let's see if this works...

@heisian

This comment has been minimized.

Copy link

@heisian heisian commented Jan 22, 2018

Alright the above doesn't really work because webpack-hot-client does us the gracious service of updating browser assets via websocket and I was trying to cut that part out completely.

So! I still need a mechanism to have the server server and the client server as separate processes... more easily done by simply having two servers on two different ports.. pretty much negating the need to write anything to disk in dev. ciao

@paulomunoz

This comment has been minimized.

Copy link

@paulomunoz paulomunoz commented Feb 2, 2018

@sokra:

But why would you need to access the generated assets? This shouldn't be required.

I would normally agree with you, but at this moment I am trying to use Visual Studio Code debugging tools to debug my app, and it only works if you provide it with the file location in disk. I used https://github.com/gajus/write-file-webpack-plugin to do the trick, and that worked fine.

Normally I would not want it to be written in the disk though, so I'll see if I can separate this in a different npm script or something like that!

@Matchlighter

This comment has been minimized.

Copy link

@Matchlighter Matchlighter commented Feb 6, 2018

Just my two cents: My project's backend is written in Python using Django. The Webpack HTTP Plugin just wouldn't cut it for my multiple-entry application, so I wrote a plugin to make Webpack write a file with all of the chunks it output and all of their required chunks. Django could then read that file and add the appropriate HTML tags. That blows up when Webpack doesn't spit out any files.
I will admit that the use case are few, but they do exist. @gajus plugin worked dandily. At least an official link in the README would be nice.

@euclid1990

This comment has been minimized.

Copy link

@euclid1990 euclid1990 commented May 24, 2018

I have released a plugin that solved this problem

https://github.com/euclid1990/write-assets-webpack-plugin

@TacB0sS

This comment has been minimized.

Copy link

@TacB0sS TacB0sS commented Oct 2, 2018

Extremely late for the party, but my 2 cents on this:

You are correct that when you are busy in developing your page and components and styles and apis, this is somewhat redundant, but when you are configuring your environment, adding third party sdks, scripts, configurations, files (and god know what other requirements they have) all that while maintaining dev and prod (maybe also staging) configurations.. things gets complicated, and although I can just execute webpack instead of webpack-dev-server and see the results, I do prefer to catch as many bird in one run...

And since you refuse adding a flag to do it.. you force us, and I do believe most of us, to just use a plugin even if just to save us few seconds every time.. cause these few second pile up eventually, and personally I hate wasting my time for no god reason.

@chrisisler

This comment has been minimized.

Copy link

@chrisisler chrisisler commented Oct 7, 2018

Just wanted to chime in to say again what has already been said: Django + webpack --watch is annoying without the awesomeness of hot reloading. Haven't tried @gajus plugin. This should be a core feature, or at least mentioned somewhere in the webpack-dev-server documentation.

@trusktr

This comment has been minimized.

Copy link

@trusktr trusktr commented Nov 14, 2018

But why would you need to access the generated assets?

Because I'm developing a library which I need to test in a browser, but I also need to import it from the file system in Node.js applications (f.e. other Electron apps that I'm also testing).

@trusktr

This comment has been minimized.

Copy link

@trusktr trusktr commented Nov 14, 2018

Essentially webpack-dev-server is designed to be used while developing apps, not while developing libraries.

@damianobarbati

This comment has been minimized.

Copy link

@damianobarbati damianobarbati commented Nov 18, 2018

Facing same issue. @sokra @trusktr in my scenario I'm trying to write a library and in the meantime watch it in an app:

const pkg = require('./package.json');
const webpack = require('webpack');
const path = require('path');

module.exports = [{
    entry: './src/index.js',
    output: {
        path: path.resolve(__dirname, './dist'),
        filename: 'dist.min.js',
        library: pkg.name,
        libraryTarget: 'umd'
    },
    watch: true,
    module: {
        rules: [{
            test: /\.(js|jsx)$/,
            exclude: /node_modules/,
            use: [{
                loader: 'babel-loader',
                options: {
                    cacheDirectory: true,
                },
            }],
        }],
    },
    externals: {
    },
},{
    entry: './demo/index.js',
    output: {
        publicPath: '/',
        path: __dirname + '/demo',
        filename: 'bundle.js'
    },
    module: {
        rules: [{
            test: /\.(js|jsx)$/,
            exclude: /node_modules/,
            use: [{
                loader: 'babel-loader',
                options: {
                    cacheDirectory: true,
                },
            }],
        }],
    },
    resolve: {
        alias: {
            Form: path.resolve(__dirname, './dist/dist.min.js'),
        },
    },
    plugins: [
        new webpack.HotModuleReplacementPlugin(),
    ],
    devServer: {
        contentBase: './demo',
        hot: true
    },
}];

The latter does not find the "resolved" => "Form" bundle on disk because it is not written.
If I trigger separated the build, subsequent changes to form bundle do not trigger dev-server "watch".

:(

@smac89

This comment has been minimized.

Copy link

@smac89 smac89 commented May 2, 2019

In webpack config:

{
   ...
    devServer: { // https://webpack.js.org/configuration/dev-server/#devserverwritetodisk-
        writeToDisk: true,
    },
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.