Description
This is not a huge problem, but it's a point of confusion that caught me when setting up my first JSR project.
Using rooted /foo.ext
globs in publish.include
will silently fail, effectively excluding everything from your package. But .gitignore supports them. 1
My project publishes to npmjs.com using yarn w/a package.json
files
array telling it which files to bundle. I also have a .gitignore
.
https://github.com/cspotcode/outdent/blob/957909edffb94a9a619368373eb3800cd8ef8829/package.json#L55-L65
https://github.com/cspotcode/outdent/blob/main/.gitignore
Both use rooted paths starting with /
. This is because a .gitignore
rule foo.ts
will ignore <root>/foo.ts
, <root>/lib/foo.ts
, <root>/test/foo.ts
whereas a rooted ignore rule /foo.ts
will only ignore <root>/foo.ts
. I use rooted patterns habitually, only using a non-rooted pattern when that is really what I want, for example node_modules
. 2
However, when configuring my jsr.jsonc
, I was caught off guard because /src
was not including my /src
directory. So my package was empty. Removing the leading slashes fixed it: https://github.com/cspotcode/outdent/blob/957909edffb94a9a619368373eb3800cd8ef8829/jsr.jsonc#L6-L9
deno publish --dry-run
made this easy to diagnose, and I love how fast it is! The confusion stemmed from assuming, incorrectly, that I could use identical syntax to my gitignore, since include
and gitignore
are so often mentioned in the same breath. I realize exact corner-case parity with git is probably not a reasonable requirement, but perhaps a quick mention in the docs would help?
Footnotes
-
Not sure if "rooted" is the correct terminology. ↩
-
A slash anywhere in the pattern makes it rooted.
https://git-scm.com/docs/gitignore
"If there is a separator at the beginning or middle (or both) of the pattern, then the pattern is relative to the directory level of the particular .gitignore file itself. Otherwise the pattern may also match at any level below the .gitignore level." ↩
Metadata
Metadata
Assignees
Labels
Type
Projects
Status