Most Pine Script users never touch libraries, and it shows: the same helper functions get pasted into script after script, and a fix in one never reaches the others. Libraries solve this. They let you write and publish reusable functions once, then import them into any script by reference. They are one of the most underused features in the language and a real marker of moving from beginner to intermediate.
What a library is
A library is a special kind of Pine script declared with library() instead of indicator() or strategy(). Inside it, you mark the functions you want to share with the export keyword. Once published on TradingView, the library gets a version, and other scripts can import it and call its exported functions as if they were built in.
//@version=6
// This is the library script
library("MyHelpers", overlay = true)
// Exported functions are callable from other scripts
export zscore(float src, simple int len) =>
basis = ta.sma(src, len)
dev = ta.stdev(src, len)
(src - basis) / dev
export isInsideBar() =>
high < high[1] and low > low[1]Importing and using it
In another script, you import the library by its author, name, and version, give it a local alias, and call its functions through that alias. The version number is part of the import, which is what makes libraries safe to depend on: a published version is immutable, so your script will not break when the author releases a new one.
//@version=6
indicator("Using a library", overlay = true)
// import <author>/<library>/<version> as <alias>
import YourName/MyHelpers/1 as helpers
z = helpers.zscore(close, 20)
inside = helpers.isInsideBar()
plot(z, "z-score")
bgcolor(inside ? color.new(color.blue, 85) : na)The exported function signatures matter here. Notice zscore takes a simple int len: library function parameters have qualifiers just like built-ins, so if you pass a value that changes every bar into a slot that expects a fixed one, you get the type errors described in the type system guide. Designing clean signatures is most of the work of a good library.
Versioning and maintenance
Because published versions are immutable, you publish updates as new versions and consumers upgrade when they choose. This is a genuine dependency model, and it rewards the same discipline as any shared code: keep exported functions focused, document what each expects and returns, and avoid changing behavior in surprising ways. Treat a library as an API other people, including future you, will depend on.
When to build one
Build a library when you notice yourself copying the same helper into multiple scripts, or when a script grows large enough that pulling the utility functions out makes it readable. Common candidates are custom indicator calculations, formatting helpers, and data-structure utilities that pair well with user-defined types. Do not build one for a single function used in a single place; the overhead is not worth it until there is real reuse.
Keeping libraries correct
The tricky part of libraries is not the syntax, it is designing signatures with the right type qualifiers and keeping exported behavior stable across versions. Those are exactly the details generic AI fumbles, because it does not model Pine's qualifier system and cannot test the published result. PineScripter writes exports with correct qualifiers and validates against TradingView, so your reusable code compiles and behaves as intended. If you are factoring shared logic into a library, you can build and refine it at PineScripter.
Disclaimer: PineScripter is a coding tool for Pine Script development. It does not provide financial advice and does not guarantee trading profits. Always backtest strategies thoroughly and understand the risks before live trading.