Revise.jl: Editing Julia Code Without Restarting the REPL

The restart tax Revise.jl removes

Julia's startup cost is not only parsing. Loading packages and waiting for code to JIT-compile is the part that hurts, and the README names exactly that overhead as what Revise saves you. The intended user is someone in the middle of a session: you have data loaded, variables defined, maybe a plot window open, and you want to change a function. Without Revise the answer is to restart Julia and rebuild all of that. With Revise the README states that changes are typically incorporated into the very next command you issue from the REPL. That is a narrow promise, and it is the right one. Revise is not a build system, a test runner or a deployment tool. It is a session-level convenience for package authors and interactive users, and the topics listed on the repository (developer-tools, jit, productivity) describe it accurately.

How Revise.jl decides what to redefine

The mechanism is not a blunt "reload the file" loop. The README states that both the 3.x and 2.x release cycles use JuliaInterpreter to step through your module-defining code. That is the part worth understanding before you adopt it. Rather than evaluating a module definition at native speed and hoping the result matches what was already loaded, Revise interprets the code that defines your module, which lets it compare the new definition against the old one and replace only the methods that changed. The 1.x release cycle took a different route: it does not use JuliaInterpreter but does integrate with Pkg.jl, and the README suggests trying it if the newer releases give you trouble, while asking you to report the problems first. So the architecture has a version boundary: 3.x and 2.x share the interpreter-based approach, 1.x does not. The practical consequence is that Revise is sensitive to how your code is written, because interpreted module definitions do not tolerate every construct the way a normal `include` does.

Installing Revise.jl and making it start by default

Revise is a registered Julia package, so installation goes through the package manager. From the Julia REPL, press `]` to enter Pkg mode and add it. The repository's Project.toml is the package manifest, and the docs directory holds the documentation site linked from the README.

using Pkg
Pkg.add("Revise")

The README is explicit that most users will want to alter their `.julia/config/startup.jl` file so Revise runs automatically, and it links to the Configuration section of the documentation for the details. The startup file lives at `.julia/config/startup.jl` in your Julia depot. Adding the import there means every new REPL session begins tracking your packages without you typing anything.

# .julia/config/startup.jl
using Revise

After that, start Julia, load a package you are developing with `using MyPackage`, edit a function body in your editor, and issue a command that calls it. According to the README, the change should be picked up by that next command rather than requiring a restart. The README also notes that Julia for VSCode and Juno offer editor-based mechanisms that achieve a subset of Revise's aims, which is a useful signal about where the full behaviour lives.

Where Revise.jl will not save you

The README's own framing is a limitation: changes are "typically" incorporated into the next command. That word is doing work. Revise replaces method definitions; it does not promise to re-run arbitrary side effects that happened at module load time, and the interpreter-based path means code that does not step cleanly through JuliaInterpreter is a candidate for trouble. The README acknowledges this history directly by keeping 1.x available for people the newer releases give trouble. If your workflow is editing a struct's field layout and expecting every existing object to be rebuilt, or changing a constant that was baked into compiled code, a restart is still the honest answer. The same goes for anything where the old method is already inlined into a caller that Revise does not recompile. Treat Revise as a fast path for method bodies and signatures, not as a guarantee that the session state is identical to a fresh start. When a change looks like it did not take, restarting Julia is the control experiment.

Revise.jl against the editor-integrated reloaders

The README points at two alternatives by name: Julia for VSCode and Juno, described as IDEs that offer an editor-based mechanism for achieving a subset of Revise's aims. The difference in approach is where the reload logic lives. An editor integration knows what you saved and can trigger a reload from inside the IDE; it only helps while you are working in that editor. Revise sits in the Julia session itself, so it does not care which editor wrote the file, and it also covers changes that arrive from outside your editor entirely. The README lists switching git branches and updating packages as things you can do mid-session, which an editor-triggered reload would not naturally catch. If you already live inside one IDE and only ever edit files there, the built-in mechanism may be enough. If you switch branches, pull package updates, or edit across several tools, the session-level approach is the one that covers all of it.

Licence, releases and upgrade cost

The repository carries a LICENSE.md at the top level, and the metadata reports the licence as NOASSERTION, meaning no standard SPDX identifier was detected. That is worth resolving yourself before you depend on Revise in a commercial setting: open LICENSE.md and read the actual terms rather than trusting the classifier. Nothing here is legal advice. On maintenance, the last push to the default branch was on 2026-09-02, and releases v3.17.0, v3.16.5 and v3.16.4 landed in August 2026, so the project is being updated. Upgrade cost is low in the ordinary case, since Revise is a development-time dependency and not something you ship to users. The version boundary is the real cost: 3.x and 2.x depend on JuliaInterpreter, while 1.x does not, so a decision to fall back to 1.x changes which code paths are exercised. The NEWS.md file at the repository root is where release-level changes are recorded, and it is the file to read before bumping across a major version.

Editorial conclusion

Adopt Revise.jl if you develop Julia packages or work interactively and want edits picked up by the next REPL command instead of a fresh session. Skip it if you only run finished scripts in batch, or if you are pinned to Julia 0.6, where the README points at a separate branch. Before relying on it, check that your package loads cleanly under the JuliaInterpreter-based 3.x path, and read the configuration page so Revise starts automatically from .julia/config/startup.jl.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. timholy/Revise.jl on GitHub