Parcel: Add a way to perform single builds for development

[devil418]

🙋 feature request

Add a way to make a single build for development without starting the watcher.

🤔 Expected Behavior

There should be a way to make a single build. The build should be identical to those generated when invoking "serve" or "watch", but Parcel should exit immediately after completing the build, regardless of whether it succeeded or failed.

😯 Current Behavior

Currently, it is possible to create builds optimized for production use or to continuously watch for changes and make new development builds when changes are detected. It is not possible to make a single development build upon request and then exit.

💁 Possible Solution

A "--dev" flag to build indicating that the build should not be optimized for production use.

🔦 Context

When developing a complex app with more than one build step, it may be desirable to use a different file watching tool and invoke parcel as a part of a more complex build pipeline. A good example is a Golang app that's compiled to a binary (a .exe file on Windows) and bundled with the javascript files. The build pipeline should look as follows:

• If a js file has changed or if this is the first build, try building the js for development (using Parcel)
• If the js compilation failed, print the error and exit.
• Generate one or more .go files containing the assets generated by Parcel.
• Compile the go program along with the generated files to a single binary that can be easily moved to another computer, deployed to a server etc.
• Start the binary.
• The binary will handle both the requests to the API and the requests for assets like the html, js and css files. All the assets are now embedded inside that single binary file and no interaction with the filesystem is needed.

In this scenario, using a Parcel Watch command that runs continuously is not appropriate, as it's impossible for a Go watcher to figure out when Parcel has finished building and when to move on with embedding the assets.

This would also be useful for programs in other languages, particularly when both a Frontend and a Backend are involved and the Backend (or a different watcher) needs to control building of the frontend during development.

[DeMoorJasper]

this command should run a dev build NODE_ENV=development parcel build <entrypoint> --no-minify

[devil418]

Does it work in exactly the same way as building while watching without actually watching?

[DeMoorJasper]

@devil418 it should create the same bundles but it doesn't watch or serve assets

[mischnic]

@devil418 Has this answered your question?

[fo-fo]

I'm getting a different content hash for a JS file generated from a TS file sourced from an HTML file when using NODE_ENV=development parcel build <entrypoint> --no-minify vs parcel watch <entrypoint>. The JS/map files are identical (save for differences in sourceMappingURL due to the changed hash).

Is this intentional?

My use case is that I want to make a full build before launching some other dev tool which expects the files to be there (I can't use watch for this because I won't know when it has completed the build).

[fo-fo]

(P.S. @devongovett can this be re-opened?)

[DeMoorJasper]

@fo-fo what you mentioned is intended behaviour. The original issue had been solved a year ago... So please open a new issue for a new question/bug/feature

[fo-fo]

@DeMoorJasper Can you explain why it's intentional that the hash differs when doing a dev build via build vs when doing it via watch? How is the hash generated anyways?

[DeMoorJasper]

@fo-fo it's based on name and parcel options, so the hash contains a boolean for watching.

[mischnic]

I think it's because parcel build sets mode: "production" and parcel watch and parcel serve set mode: "development".
https://github.com/parcel-bundler/parcel/blob/f01437e7f646f4aa74a5d3cf48ed7c4f21822352/packages/core/parcel-bundler/src/cli.js#L215-L224

So "watch" is rather "serve without server" than "build continuously"

[fo-fo]

@DeMoorJasper @mischnic Okay, makes sense that build flags affect the hash, thanks. I think I will not make an issue for this because it's just a cosmetic issue (extra files end up in the dist directory, but nevertheless the references from other files are correct).