Adapter API to parse ignore files to warn of suggested ignores

[jthegedus]

Describe the problem

Different adapters require different ignore settings.

The current proposed soln that is in use today is for all adapter output to be under .svelte-kit/<somedir> though this may change in future per adapter.

The proposed solution would provide adapter authors with an alternative.

Describe the proposed solution

Use gitignore-parser to let Adapters to loudly warn users. From this exchange:

Should we expect to see gitignore-parser provided via the Adapter API in the near future?

• jthegedus [fix] revert adapters automatically updating .gitignore (#1924) #2055 (comment)

Yes, I think we should — we could have an API like utils.warn_if_unignored([opts.output])

• Rich-Harris [fix] revert adapters automatically updating .gitignore (#1924) #2055 (comment)

Alternatives considered

Writing this in my documentation

Importance

would make my life easier

Additional Information

raising the issues:

• Adapter build outputs are linted, formatted, and synced to Git #1832
• kit@110: removed lines from .gitignore in demo project #1581

initial proposition:

• [feat] Ignore adapter build files #1924

revert of initial proposition

• [fix] revert adapters automatically updating .gitignore (#1924) #2055

[benmccann]

https://kit.svelte.dev/docs#writing-an-adapter says:

If possible, we recommend putting the adapter output under the build/ directory with any intermediate output placed under '.svelte-kit/' + adapterName.

Unfortunately it hasn't always been possible. We had to move some of the Netlify output to be under .netlify

[jthegedus]

kit.svelte.dev/docs#writing-an-adapter says:

If possible, we recommend putting the adapter output under the build/ directory with any intermediate output placed under '.svelte-kit/' + adapterName.

Unfortunately it hasn't always been possible. We had to move some of the Netlify output to be under .netlify

Yes, this cannot always be achieved. If the adapter reads the platform config (netlify.toml, firebase.json etc) to determine where to put the final build output, then a way to warn about ignoring is required.

A key point to highlight, and that I think is missed in a lot of the Kit > PlatformX conversations, is the idea that Kit is the only App & owner of all APIs hosted on PlatformX. For instance, a single Firebase project can house many Android, iOS, Web apps and APIs all from the same firebase.json config, which is why the Firebase Adapter cannot simply put everything in build/ nor that build/ is even at the root of the Firebase project. But also, does not mean the user wants to commit the final build output wherever it lives.