Publishing, libraries and next steps

A script that works is worth sharing, or at least worth keeping in a form your future self can reuse. This last lesson covers the three visibility options when you publish, how to move shared code into a library, and where to go after this course.

Publishing a script

From the editor, "Publish script" opens a form: title, description, visibility (public or private to your profile), and a source option. Publishing creates a page on TradingView with the chart image, the description and, depending on the source option, the code. Anyone can then add the script from the community scripts search.

The three source options:

• Open-source. The code is visible. Readers can copy it, learn from it and check it for lookahead and repainting. For anything you want people to trust, this is the option; a signal script whose code is hidden asks for trust it cannot earn.
• Protected. Anyone can add the script, nobody can read the code. Useful when you would rather not reveal an implementation but still want it freely usable.
• Invite-only. Only users you add to a list can use it. This is the mechanism vendors use for paid access; TradingView's rules for vendors are strict and change, and this course does not cover selling scripts.

Public publications must follow TradingView's House Rules: the description has to explain what the script does and how to use it, in enough detail that a reader can judge it; marketing language and unsupported performance claims are grounds for moderation. Private publications are exempt from most of that but still cannot be edited after publishing; to change one, publish an update.

A good description, whatever the visibility, answers: what it calculates, which inputs matter, whether it repaints (and why not), what timeframe and markets it was designed for, and what its alerts say.

Libraries

When two of your scripts contain the same function, move it to a library. A library is a script declared with library() whose exported functions can be imported by other scripts.

//@version=6
// @description Position sizing helpers for risk-based entries.
library("SizingLib", overlay=true)

// @function Whole units to trade for a given dollar risk and stop distance.
// @param riskDollars Currency amount you are willing to lose on the trade.
// @param stopDistance Distance from entry to stop, in price units.
// @returns Whole number of units; 0 when either input is not positive.
export unitsForRisk(float riskDollars, float stopDistance) =>
    riskDollars > 0 and stopDistance > 0 ? math.floor(riskDollars / stopDistance) : 0

// @function Percent of equity a given dollar risk represents.
// @param riskDollars Currency at risk.
// @param equity Current account equity.
// @returns Percent, or 0 when equity is not positive.
export riskPercent(float riskDollars, float equity) =>
    equity > 0 ? riskDollars / equity * 100 : 0.0

Rules for libraries:

• Exported functions must declare parameter types.
• They cannot use plot, strategy.* orders, input.* or alertcondition; they compute, they do not draw or trade.
• The // @function, // @param and // @returns comments are read by the editor and shown as tooltips to users of the library.
• A library must be published (public or private) before it can be imported; version numbers increment on each update.

Importing, in any script:

//@version=6
import yourusername/SizingLib/1 as sz
strategy("Uses SizingLib", overlay=true)
atr = ta.atr(14)
qty = sz.unitsForRisk(strategy.equity * 0.01, atr * 2)
plot(qty, "Units", display=display.data_window)

The path is username/LibraryName/version. Pinning the version means an update to the library cannot silently change a strategy that depends on it.

Version control outside TradingView

The editor keeps your scripts, but it is not a history. Copy scripts into a local folder under git, or at minimum into a notes file with dates, and put a version comment at the top of every script (// v1.3 2026-05-02: ATR stop instead of fixed). When an alert misbehaves months later you will want to know exactly which version it was created from.

Where to go next

• The reference manual and user manual. The reference is the exhaustive list; the user manual has long-form chapters on execution model, repainting, strategies and drawing that go deeper than this course. Both are in the editor's help menu and are the first place to look.
• Reading open-source scripts. Find a well-rated open-source script that does something close to what you want, read it end to end, and identify every idiom from this course. Then look for anything that repaints.
• The risk-management course on this site is the arithmetic that module 6's sizing and module 7's drawdown reading rest on; if you skipped it, go back.
• Build the projects for your market. Change the session, the sizing units and the costs to match what you actually trade, and run the full testing sequence from module 7. That sequence, not any single script, is the transferable skill.

Key idea: Publish open-source when you want trust, protected when you want to hide an implementation, invite-only for access lists; move shared functions into a versioned library; keep your own version history outside the editor.

Try it: Publish the sizing library privately, import it into the pullback strategy from the previous lesson, and replace the inline sizing lines with sz.unitsForRisk. Then write the strategy's description as if for a public publication: what it does, its inputs, its repainting status, its intended markets and what its alerts say.

Recap

• Publishing offers open-source, protected and invite-only; open-source is the only one that lets users verify the code.
• Descriptions must explain function, inputs, repainting status and intended use; unsupported claims get moderated.
• library() with exported, typed functions packages reusable code; import with username/Name/version.
• Libraries compute only; no plots, orders, inputs or alert conditions.
• Keep versions outside the editor, and keep the module 7 testing sequence as the habit that outlasts any single script.