# How to check for errors when creating package/class

Short: How can you find errors in a package/class without importing the .cls/.sty file to your project/without using the package?

Note: I'm looking for a general way of checking package/class errors, not for help locating (specific) errors in the V1 package.

I've been writing packages (.sty) and classes (.cls) recently and sometimes when I load them I get errors that occur in the package/class files. I write LaTeX in Overleaf and to use my packages and classes I import them from a project where I keep all my .sty/.cls files. So the file in the project looks like this:

The problem is that if it is an error in the package, it will only appear in the main.txt file and it will not show where in the package (.sty) the error is.

For instance, when I use the package V1 I get this error:

But it works just fine when I do not use the package V1, so I know the problem is either inside the package V1 or something regarding the package V1.

Sometimes it can be missing  that cause errors, or other things. The annoying thing is it will only display the error where I load the package and not in the package itself. So in this example, I have to read through the entire package and maybe guess where there are missing \$-signs.

So my question(s) is:

How can you find errors in a package/class? How can you do that without using/importing the package? Is there a way to check for errors and display them without having to test the package and commands in a document.txt file? A button that checks the .cls/.sty file for compiling errors or something?

• Using Overleaf for testing packages/classes is not something I'd try. – egreg Nov 7 '19 at 15:13

(Disclosure: I'm on support staff at Overleaf.)

Another answer has already addressed the questions of file/line reporting and determining if a package or class is syntactically correct a priori. I'll address the Overleaf-specific parts of the question.

When you import a file to your Overleaf project from another project, by design it is not meant to be edited within the new project. The purpose of this feature is to have one source project where a file can be edited. Then any projects that link to the file will get a read-only display of that file visible in the editor.

If you have your heart set on developing packages/classes on Overleaf, this development work should be done in the original source project, not in any other project with links to the package file(s). You can have a test document in the project where you're also developing the package/class, to easily test things. Once the package/class is developed and stable, then you can start using the file in your other Overleaf projects if you wish. (Or you can refresh any existing links to your custom package to make the new developments available in your projects.)

And I'll also mention that in normal cases Overleaf will report file/line numbers in a package or class (just like any TeX distribution you can run on your own computer). For example, the following code:

\documentclass{article}
\usepackage{custom-pkg}

\begin{document}
Some text.
\end{document}


With a file in the project called custom-pkg.sty:

\ProvidesPackage{custom-pkg}

\ifnum\the\year 2019
\def\mycustom{This is some macro from my package.}
\fi


Will result in the following raw log output1:

(/compile/custom-pkg.sty
Package: custom-pkg
! Missing = inserted for \ifnum.
\def
l.4   \def
\mycustom{This is some macro from my package.}
I was expecting to see <', =', or >'. Didn't.

! Missing number, treated as zero.
\def
l.4   \def
\mycustom{This is some macro from my package.}
A number should have been here; I inserted 0'.
(If you can't figure out why I needed to see a number,
look up weird error' in the index to The TeXbook.)

)


Or, in Overleaf's log summary (similar to what you might find in many other (La)TeX editors):

which can be clicked to directly open the .sty file at line 4 where the error was reported. So there may be another error in your package file that's preventing the line number reporting from working properly. (And I assume you would see the same behavior if you compile using a locally-installed TeX distribution as well.

The test project I used is available on Overleaf for reference.

1: For any astute readers, the compile/ subdirectory is a result of the compiler architecture on Overleaf. A file compiled with a local TeX installation will not have this extra subdirectory listed.

I can't answer specific to Overleaf, but in general, it can be difficult to test packages and classes when imported because you don't get accurate line numbers for where TeX chokes. It will often give you enough of the line to find it, but failing that, you can be in trouble.

The thing is that TeX is a macro language; it's very hard to take an individual file and say, "This is valid TeX," without actually feeding it to TeX and seeing what it says. That's why converting TeX to other formats is so difficult, too; TeX is really the only thing that can parse a TeX file for correctness.

One option is to insert the package code into the preamble of a LaTeX document (remember to surround it with \makeatletter and \makeatother commands, if you're using @ as a letter character, which you definitely should if these packages are for wider consumption) and compile it there. TeX will then report any errors with the line number.

I don't believe that it's possible to scan a package or class file and say, "This is correct"; you need to give TeX a file that it can fully compile. The syntonly` package might be worth looking at, if you just don't want to generate any output; but you will have to give it a compilable file if you want to see if it works.