Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect warning on clasp pull? #851

Open
ethanresnick opened this issue Jul 1, 2021 · 4 comments
Open

Incorrect warning on clasp pull? #851

ethanresnick opened this issue Jul 1, 2021 · 4 comments

Comments

@ethanresnick
Copy link

ethanresnick commented Jul 1, 2021

Expected Behavior

After I do a clasp pull, I get an warning message in the output that says:

Warning: files in subfolder are not accounted for unless you set a '.claspignore' file.

I'm pretty sure this warning is not correct, because I think there are default claspignore rules that do account for (i.e., do not ignore) script/html files in subfolders. Is that correct? If so, I would expect not to see this warning.

Actual Behavior

The warning above.

Specifications

  • Node version (node -v): 15.0.1
  • Version (clasp -v): 2.3.2
  • OS (Mac/Linux/Windows): Mac
@PopGoesTheWza
Copy link
Collaborator

PopGoesTheWza commented Jul 2, 2021

This warning is by design and its history is difficult to track back.

clasp/src/messages.ts

Lines 105 to 108 in d6fbaae

CLONE_SUCCESS: (
fileCount: number
) => `Warning: files in subfolder are not accounted for unless you set a '${ignore.resolve()}' file.
Cloned ${fileCount} ${fileCount === 1 ? 'file' : 'files'}.`,

It is always displayed with clone, create and pull commands, and is no longer aligned with the default set of patterns

clasp/src/dotfile.ts

Lines 39 to 52 in d6fbaae

const defaultClaspignore = `# ignore all files…
**/**
# except the extensions…
!appsscript.json
!**/*.gs
!**/*.js
!**/*.ts
!**/*.html
# ignore even valid files if in…
.git/**
node_modules/**
`;

@sqrrrl any thoughts about leaving as is or updating the message?

@ethanresnick
Copy link
Author

@PopGoesTheWza Yeah, that’s what I was getting at: since it no longer aligns with the actual fallback behavior when there’s no user-provided claspignore, it just seems misleading/confusing and it made me wonder if I actually was doing something risky that I didn’t understand

@sqrrrl
Copy link
Member

sqrrrl commented Aug 9, 2021

+1 -- noticed this earlier today and we can either drop it or at least tighten up the conditions where it's displayed.

@PopGoesTheWza
Copy link
Collaborator

Who votes it drop it? I surely do...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants