You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.jsonfiles array telling it which files to bundle. I also have a .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
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." ↩
The text was updated successfully, but these errors were encountered:
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 inpublish.include
will silently fail, effectively excluding everything from your package. But .gitignore supports them. 1My 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
rulefoo.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 examplenode_modules
. 2However, 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-L9deno 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, sinceinclude
andgitignore
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." ↩
The text was updated successfully, but these errors were encountered: